» » » Настройка отказоустойчивого управляющего сервера Apache CloudStack с использованием репликации MariaDB Galera

 

Настройка отказоустойчивого управляющего сервера Apache CloudStack с использованием репликации MariaDB Galera

Автор: admin от 19-07-2017, 05:00, посмотрело: 559

Настройка отказоустойчивого управляющего сервера Apache CloudStack с использованием репликации MariaDB Galera
После моих первой и второй статей об Apache CloudStack ко мне обратился пользователь с вопросом о том, как организовать высокодоступный управляющий сервер ACS с использованием Galera. Ранее я не использовал такую топологию развертывания, но по этому поводу решил попробовать выполнить такую настройку.



В статье описывается метод развертывания отказоустойчивой конфигурации управляющих серверов Apache CloudStack совместно с мультимастер-кластером MariaDB (Galera).При разработке данной инструкции использовались следующие версии программных продуктов:




  • Apache CloudStack 4.9.2

  • CentOS 7

  • MariaDB 5.5.52 (по-умолчанию в CentOS 7)

  • Ansible 2.3.1 (по-умолчанию в CentOS 7)



  • Целевая модель развертывания системы отображена на следующем рисунке.



    Настройка отказоустойчивого управляющего сервера Apache CloudStack с использованием репликации MariaDB Galera

    В рамках данной модели каждый сервер ACS связан с локальным сервером MySQL. В некоторых англоязычных руководствах предлагается использовать промежуточный компонент HAProxy для балансировки соединений к MariaDB таким образом, что каждый сервер ACS может прозрачно переключаться между серверами при отказе, однако, на мой взгляд, достаточно внешнего переключения трафика между серверами ACS, которую можно настроить с помощью Nginx, при этом каждый сервер ACS оказывается связан с локальной репликой MariaDB. В случае отказа реплики MariaDB, будет потерян один сервер ACS, но Nginx переключит трафик на другой доступный.



    Общая схема развертывания



    Рассмотрим общую схему процесса развертывания всей системы и исходные допущения.



    MariaDB



    Для развертывания кофигурации MariaDB будет использоваться плэйбук Ansible, доступный на

    GitHub. Данный подход позволяет акцентировать внимание статьи именно на том, как установить ACS, но не настройке кластера Galera. Поскольку вышеуказанный плэйбук разработан для использования совместно с CentOS 7, то операционная система выбрана соответствующим образом. В том случае, если читатель планирует выполнить аналогичную настройку на другой совместимой с ACS 4.9.2 операционной системе, общая схема остается такой же.



    плэйбук не мой. В репозитории видно откуда сделан форк. Относительно оригинального он немного поправлен с целью поддержки сети на eth0.


    Apache CloudStack



    Как бы странно это не звучало, но установить ACS 4.9.2 на работающий кластер Galera нельзя. Данное ограничение возникает в связи с тем, что сервер управления при установке создает базу данных для версии 4.0, которая преобразуется в базу данных версии 4.9.2 цепочкой миграций. Поскольку в процессе первоначальной установки и миграций используются неподдерживаемые кластерной версией Galera движки баз данных (используемые в младших версиях ACS), то процесс не завершается успешно.



    Для преодоления данной проблемы мы будем выполнять установку в несколько этапов:




  • Установка ACS 4.9.2 на обычный сервер MySQL, снятие дампа баз данных.

  • Импорт баз данных в кластер Galera.

  • Подключение серверов управления к кластеру Galera.



  • На выходе будет получена рабочая топология, отображенная на первом рисунке.



    Испытательный стенд



    Развертывание будем производить на 4х хостах:




  • ac — хост CentOS 7 с установленным ansible, с которого мы будем осуществлять конфигурирование оставшихся хостов, и где выполним первоначальное развертывание ACS 4.9.2 без использования Galera;

  • h1, h2, h3 — хосты CentOS 7, на которых будет установлена кластерная версия ACS 4.9.2 и Galera.



  • Плэйбук развертывания кластера Galera предполагает, что хосты находятся в защищенной сети (упрощенная настройка файрвола), доступной посредством сетевой карты eth0. Плэйбук предполагает, что служба firewalld используется.



    Базовая установка (без HA)



    Установим на хост ac базовые компоненты:



    # yum install epel-release 
    # yum install net-tools git mariadb mariadb-server ansible


    Запускаем MariaDB:



    # systemctl start mariadb


    Проверяем, что MariaDB работает:



    # mysql -uroot
    Welcome to the MariaDB monitor.  Commands end with ; or g.
    Your MariaDB connection id is 2
    Server version: 5.5.52-MariaDB MariaDB Server
    
    Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.
    
    Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.
    
    MariaDB [(none)]>


    Вносим в настройки сервера MariaDB (/etc/my.cnf.d/server.cnf) рекомендуемые ACS опции в секцию [mysql]:



    [mysql]
    innodb_rollback_on_timeout=1
    innodb_lock_wait_timeout=600
    max_connections=350
    log-bin=mysql-bin
    binlog-format = 'ROW'


    Перезапускаем MariaDB:



    # systemctl restart mariadb


    Создадим файл репозитория Yum для Apache CloudStack /etc/yum.repos.d/cloudstack.repo со следующим содержимым:



    [cloudstack]
    name=cloudstack
    baseurl=http://cloudstack.apt-get.eu/centos/7/4.9/
    enabled=1
    gpgcheck=0


    Установим пакет управляющего сервера ACS:



    # yum install cloudstack-management


    Редактируем файл безопасности Java:



    # grep -l '/dev/random' /usr/lib/jvm/java-*/jre/lib/security/java.security /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-3.b12.el7_3.x86_64/jre/lib/security/java.security


    где заменяем генератор случайных чисел (требуется для библиотеки шифрования, используемой в ACS):



    # sed -i 's#securerandom.source=file:/dev/random#securerandom.source=file:/dev/urandom#' /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-3.b12.el7_3.x86_64/jre/lib/security/java.security


    Изменяем политику SELinux на permissive в файле:



    # sed -i 's#SELINUX=enforcing#SELINUX=permissive#' /etc/selinux/config


    Запускаем установку БД ACS (с доступом к MariaDB cloud/secret) от пользователя root (локальный пароль доступа к СУБД не требуется):



    # cloudstack-setup-databases cloud:secret@localhost --deploy-as=root
    Mysql user name:cloud                                                           [ OK ]
    Mysql user password:******                                                      [ OK ]
    Mysql server ip:localhost                                                       [ OK ]
    Mysql server port:3306                                                          [ OK ]
    Mysql root user name:root                                                       [ OK ]
    Mysql root user password:******                                                 [ OK ]
    Checking Cloud database files ...                                               [ OK ]
    Checking local machine hostname ...                                             [ OK ]
    Checking SELinux setup ...                                                      [ OK ]
    Detected local IP address as 176.120.25.66, will use as cluster management server node IP[ OK ]
    Preparing /etc/cloudstack/management/db.properties                              [ OK ]
    Applying /usr/share/cloudstack-management/setup/create-database.sql             [ OK ]
    Applying /usr/share/cloudstack-management/setup/create-schema.sql               [ OK ]
    Applying /usr/share/cloudstack-management/setup/create-database-premium.sql     [ OK ]
    Applying /usr/share/cloudstack-management/setup/create-schema-premium.sql       [ OK ]
    Applying /usr/share/cloudstack-management/setup/server-setup.sql                [ OK ]
    Applying /usr/share/cloudstack-management/setup/templates.sql                   [ OK ]
    Processing encryption ...                                                       [ OK ]
    Finalizing setup ...                                                            [ OK ]
    
    CloudStack has successfully initialized database, you can check your database configuration in 
    /etc/cloudstack/management/db.properties


    Запускаем установку сервера управления:



    # cloudstack-setup-management --tomcat7
    Starting to configure CloudStack Management Server:
    Configure Firewall ...        [OK]
    Configure CloudStack Management Server ...[OK]
    CloudStack Management Server setup is Done!


    Проверяем через несколько секунд доступность сервера (http://ac:8080/client):



    # LANG=C wget -O /dev/null http://ac:8080/client 2>&1 | grep '200 OK'
    HTTP request sent, awaiting response... 200 OK


    Рекомендую зайти с помощью браузера на URL и убедиться, что сервер работает и позволяет аутентифицироваться с помощью пары admin/password. Если все отрабатывает, значит установка сервера управления успешно произведена.



    Теперь сохраним дампы баз данных для дальнейшего импорта на кластер Galera:



    # mysqldump -uroot cloud >cloud.sql
    # mysqldump -uroot cloud_usage >cloud_usage.sql


    Убедимся, что все таблицы имеют формат InnoDB:



    # grep ENGINE *.sql | grep -v InnoDB | grep -v -c '*/'
    0


    Настройка реплицируемой среды Galera



    Развертывание кластера Galera будем производить с использованием Ansible. Ansible работает по протоколу SSH, поэтому необходимо на хосты h1, h2, h3 положить публичную часть ключей SSH, для хоста ac.



    Сгенерируем ключ SSH на хосте ac:



    # ssh-keygen 
    Generating public/private rsa key pair.
    Enter file in which to save the key (/root/.ssh/id_rsa): 
    Enter passphrase (empty for no passphrase): 
    Enter same passphrase again: 
    Your identification has been saved in /root/.ssh/id_rsa.
    Your public key has been saved in /root/.ssh/id_rsa.pub.
    The key fingerprint is:
    30:81:f7:90:f0:4f:e0:d4:8a:74:ca:40:ba:d9:c7:8e root@ac
    The key's randomart image is:
    +--[ RSA 2048]----+
    | .. .o+o         |
    | .. o+=o.        |
    |.  + ==+.        |
    | + .+ .=.        |
    |o . o   S        |
    |   +             |
    |  E .            |
    |                 |
    |                 |
    +-----------------+


    Распространим ключ на все хосты:



    # ssh-copy-id h1
    The authenticity of host 'h1 (X.Y.Z.C)' can't be established.
    ECDSA key fingerprint is 27:f7:34:23:ea:b4:d2:61:8c:ec:d8:13:c2:9f:8a:ef.
    Are you sure you want to continue connecting (yes/no)? yes
    /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
    /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
    root@h1's password: 
    
    Number of key(s) added: 1
    
    Now try logging into the machine, with:   "ssh 'h1'"
    and check to make sure that only the key(s) you wanted were added.


    Аналогичные действия проделаем для хостов h2 и h3.



    Теперь необходимо клонировать Git-репозиторий с плэйбуком Ansible:



    # git clone https://github.com/bwsw/mariadb-ansible-galera-cluster.git
    Cloning into 'mariadb-ansible-galera-cluster'...
    remote: Counting objects: 194, done.
    remote: Compressing objects: 100% (5/5), done.
    remote: Total 194 (delta 0), reused 2 (delta 0), pack-reused 188
    Receiving objects: 100% (194/194), 29.91 KiB | 0 bytes/s, done.
    Resolving deltas: 100% (68/68), done.


    Сменим каталог на mariadb-ansible-galera-cluster:



    # cd mariadb-ansible-galera-cluster
    # pwd
    /root/mariadb-ansible-galera-cluster


    Отредактируем файл galera.hosts, где укажим наши серверы h1, h2, h3:



    [galera_cluster]
    h[1:3] ansible_user=root


    Проверим корректность конфигурации:



    # ansible -i galera.hosts all -m ping
    h3 | SUCCESS => {
        "changed": false, 
        "ping": "pong"
    }
    h2 | SUCCESS => {
        "changed": false, 
        "ping": "pong"
    }
    h1 | SUCCESS => {
        "changed": false, 
        "ping": "pong"
    }


    Установим необходимые зависимости:



    # ansible -i galera.hosts all -m raw -s -a "yum install -y epel-release firewalld ntpd"


    Обновим системное время:



    # ansible -i galera.hosts all -m raw -s -a "chkconfig ntpd on && service ntpd stop && ntpdate 165.193.126.229 0.ru.pool.ntp.org 1.ru.pool.ntp.org 2.ru.pool.ntp.org 3.ru.pool.ntp.org && service ntpd start"


    Внесем необходимые изменения в файл конфигурации ansible (/etc/ansible/ansible.cfg), как описано в

    README.md к плэйбуку:



    [defaults]
    gathering = smart
    fact_caching = jsonfile
    fact_caching_connection = ~/.ansible/cache


    Приступим к установке кластера Galera согласно README.md плэйбука:



    # ansible-playbook -i galera.hosts galera.yml --tags setup


    Это займет несколько минут, по итогам выполнения мы получим установленные серверы MariaDB на хостах h1, h2, h3 без сборки кластера. Следующим шагом необходимо запустить оставшиеся шаги плэйбука:



    # ansible-playbook -i galera.hosts galera.yml --skip-tags setup


    Последний шаг — запуск кластера:



    # ansible-playbook -i galera.hosts galera_bootstrap.yml


    Проверим статус кластера. Для этого зайдем на хосты h1, h2, h3 и в консоли mysql выполним:



    # mysql -uroot
    Welcome to the MariaDB monitor.  Commands end with ; or g.
    Your MariaDB connection id is 6
    Server version: 10.1.25-MariaDB MariaDB Server
    
    Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
    
    Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.
    
    MariaDB [(none)]> SHOW GLOBAL STATUS LIKE 'wsrep_%';
    +------------------------------+------------------------------------------------------------+
    | Variable_name                | Value                                                      |
    +------------------------------+------------------------------------------------------------+
    | wsrep_apply_oooe             | 0.000000                                                   |
    | wsrep_apply_oool             | 0.000000                                                   |
    | wsrep_apply_window           | 0.000000                                                   |
    | wsrep_causal_reads           | 0                                                          |
    | wsrep_cert_deps_distance     | 0.000000                                                   |
    | wsrep_cert_index_size        | 0                                                          |
    | wsrep_cert_interval          | 0.000000                                                   |
    | wsrep_cluster_conf_id        | 3                                                          |
    | wsrep_cluster_size           | 3                                                          |
    | wsrep_cluster_state_uuid     | 230ed410-6b9b-11e7-8aa5-4b041fceb486                       |
    | wsrep_cluster_status         | Primary                                                    |
    | wsrep_commit_oooe            | 0.000000                                                   |
    | wsrep_commit_oool            | 0.000000                                                   |
    | wsrep_commit_window          | 0.000000                                                   |
    | wsrep_connected              | ON                                                         |
    | wsrep_desync_count           | 0                                                          |
    | wsrep_evs_delayed            |                                                            |
    | wsrep_evs_evict_list         |                                                            |
    | wsrep_evs_repl_latency       | 0/0/0/0/0                                                  |
    | wsrep_evs_state              | OPERATIONAL                                                |
    | wsrep_flow_control_paused    | 0.000000                                                   |
    | wsrep_flow_control_paused_ns | 0                                                          |
    | wsrep_flow_control_recv      | 0                                                          |
    | wsrep_flow_control_sent      | 0                                                          |
    | wsrep_gcomm_uuid             | 230d9f4f-6b9b-11e7-ba99-fab39514a7e8                       |
    | wsrep_incoming_addresses     | 111.120.25.96:3306,111.120.25.229:3306,111.120.25.152:3306 |
    | wsrep_last_committed         | 0                                                          |
    | wsrep_local_bf_aborts        | 0                                                          |
    | wsrep_local_cached_downto    | 18446744073709551615                                       |
    | wsrep_local_cert_failures    | 0                                                          |
    | wsrep_local_commits          | 0                                                          |
    | wsrep_local_index            | 0                                                          |
    | wsrep_local_recv_queue       | 0                                                          |
    | wsrep_local_recv_queue_avg   | 0.000000                                                   |
    | wsrep_local_recv_queue_max   | 1                                                          |
    | wsrep_local_recv_queue_min   | 0                                                          |
    | wsrep_local_replays          | 0                                                          |
    | wsrep_local_send_queue       | 0                                                          |
    | wsrep_local_send_queue_avg   | 0.000000                                                   |
    | wsrep_local_send_queue_max   | 1                                                          |
    | wsrep_local_send_queue_min   | 0                                                          |
    | wsrep_local_state            | 4                                                          |
    | wsrep_local_state_comment    | Synced                                                     |
    | wsrep_local_state_uuid       | 230ed410-6b9b-11e7-8aa5-4b041fceb486                       |
    | wsrep_protocol_version       | 7                                                          |
    | wsrep_provider_name          | Galera                                                     |
    | wsrep_provider_vendor        | Codership Oy <info@codership.com>                          |
    | wsrep_provider_version       | 25.3.20(r3703)                                             |
    | wsrep_ready                  | ON                                                         |
    | wsrep_received               | 10                                                         |
    | wsrep_received_bytes         | 769                                                        |
    | wsrep_repl_data_bytes        | 0                                                          |
    | wsrep_repl_keys              | 0                                                          |
    | wsrep_repl_keys_bytes        | 0                                                          |
    | wsrep_repl_other_bytes       | 0                                                          |
    | wsrep_replicated             | 0                                                          |
    | wsrep_replicated_bytes       | 0                                                          |
    | wsrep_thread_count           | 2                                                          |
    +------------------------------+------------------------------------------------------------+
    58 rows in set (0.01 sec)
    
    MariaDB [(none)]> 


    Обратите внимание на поле wsrep_incoming_addresses, там должны быть IP-адреса трех наших серверов h1, h2, h3.



    Установка серверов управления для реплицируемой среды Galera



    Следующий шаг — импорт дампов cloud.sql и cloud_usage.sql в кластер.



    Копируем дампы:



    # scp ../*.sql h1:
    cloud.sql                                     100% 1020KB   1.0MB/s   00:00
    cloud_usage.sql                               100%   33KB  32.7KB/s   00:00


    Откроем SSH-соединение на хост h1, где выполним все операции по импорту баз данных:



    # ssh h1


    Создадим базы данных, выдадим привилегии пользователю и импортируем дампы:



    [root@h1 ~]# echo "CREATE DATABASE cloud;" | mysql -uroot
    [root@h1 ~]# echo "CREATE DATABASE cloud_usage;" | mysql -uroot
    [root@h1 ~]# echo "GRANT ALL PRIVILEGES ON cloud.* TO  cloud@'localhost' identified by 'secret'" | mysql -uroot
    [root@h1 ~]# echo "GRANT ALL PRIVILEGES ON cloud_usage.* TO  cloud@'localhost' identified by 'secret'" | mysql -uroot
    [root@h1 ~]# cat cloud.sql | mysql -uroot cloud
    [root@h1 ~]# cat cloud_usage.sql | mysql -uroot cloud_usage


    Стоит убедиться в том, что наши базы cloud, cloud_usage реплицируются на серверы h2 и h3.

    Теперь будем устанавливать управляющие серверы ACS. Сначала с хоста ac скопируем настройки репозитория ACS:



    # ansible -i galera.hosts all -m copy -a "src=/etc/yum.repos.d/cloudstack.repo dest=/etc/yum.repos.d/cloudstack.repo"


    Затем установим пакеты управляющего сервера Apache CloudStack:



    # ansible -i galera.hosts all -m raw -s -a "yum install -y cloudstack-management"


    Изменим уже известную нам настройку безопасности Java:



    # [root@ac mariadb-ansible-galera-cluster]# ansible -i galera.hosts all -m raw -s -a "sed -i 's#securerandom.source=file:/dev/random#securerandom.source=file:/dev/urandom#' /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.131-3.b12.el7_3.x86_64/jre/lib/security/java.security"


    Выполним настройку подключения управляющего сервера ACS к СУБД на локальном хосте:



    # ansible -i galera.hosts all -m raw -s -a "cloudstack-setup-databases cloud:secret@localhost"


    Запускаем управляющие серверы:



    # ansible -i galera.hosts all -m raw -s -a "cloudstack-setup-management --tomcat7"


    Убедимся, что все запущено и работает:



    # ansible -i galera.hosts all -m raw -s -a "ps xa | grep java"


    Теперь, на адресах http://h1:8080/client, http://h2:8080/client, http://h3:8080/client выполняются отказоустойчивые управляющие серверы, которые можно "закрыть" nginx для обеспечения высокой доступности. При этом в журнале /var/log/cloudstack/management/management-server.log можно увидеть записи о том, что серверы знают друг о друге:



    # cat /var/log/cloudstack/management/management-server.log | grep 'management node'
    2017-07-18 17:05:27,209 DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-b1d64593) (logid:18f29c84) Detected management node joined, id:7, nodeIP:111.120.25.96
    2017-07-18 17:05:27,231 DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-b1d64593) (logid:18f29c84) Detected management node joined, id:12, nodeIP:111.120.25.152
    2017-07-18 17:05:27,231 DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-b1d64593) (logid:18f29c84) Detected management node joined, id:17, nodeIP:111.120.25.229
    2017-07-18 17:05:33,195 DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-76484aea) (logid:b7416e7b) Detected management node left and rejoined quickly, id:7, nodeIP:111.120.25.96
    2017-07-18 17:07:22,582 INFO  [c.c.c.ClusterManagerImpl] (localhost-startStop-1:null) (logid:) Detected that another 
    management node with the same IP 111.120.25.229 is considered as running in DB, however it is not pingable, we will continue cluster initialization with this management server node
    2017-07-18 17:07:33,292 DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-8880f35d) (logid:037a1c4d) Detected management node joined, id:7, nodeIP:111.120.25.96
    2017-07-18 17:07:33,312 DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-8880f35d) (logid:037a1c4d) Detected management node joined, id:12, nodeIP:111.120.25.152
    2017-07-18 17:07:33,312 DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-8880f35d) (logid:037a1c4d) Detected management node joined, id:17, nodeIP:111.120.25.229
    2017-07-18 17:12:41,927 DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-7e3e2d82) (logid:e63ffa72) Detected management node joined, id:7, nodeIP:111.120.25.96
    2017-07-18 17:12:41,935 DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-7e3e2d82) (logid:e63ffa72) Detected management node joined, id:12, nodeIP:111.120.25.152
    2017-07-18 17:12:41,935 DEBUG [c.c.c.ClusterManagerImpl] (Cluster-Heartbeat-1:ctx-7e3e2d82) (logid:e63ffa72) Detected management node joined, id:17, nodeIP:111.120.25.229


    Заключение



    Настройка достаточно простая и не должна вызвать каких-либо сложностей. Несколько расстраивает, что невозможно выполнить установку на кластер Galera сразу, без выполнения процедуры переноса из нереплицируемой среды в реплицируемую после установки.



    Источник: Хабрахабр

    Категория: Админитстрирование » Системное администрирование

    Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
    Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

    Добавление комментария

    Имя:*
    E-Mail:
    Комментарий:
    Полужирный Наклонный текст Подчеркнутый текст Зачеркнутый текст | Выравнивание по левому краю По центру Выравнивание по правому краю | Вставка смайликов Выбор цвета | Скрытый текст Вставка цитаты Преобразовать выбранный текст из транслитерации в кириллицу Вставка спойлера
    Введите два слова, показанных на изображении: *