Knowledge base
Jak wykorzystać infrastrukturę Oktawave w celu zapewnienia wysokiej dostępności baz danych MySQL?
Posted by Pomoc Oktawave on 28.10.2014 20:22

W Oktawave możesz samodzielnie skonfigurować dowolną topologię replikacji baz danych, jednak w pewnych przypadkach nasza infrastruktura może ci w tym pomóc, na przykład poprzez load balancer oraz Autoskaler.

 

1. Replikacja Master-Slave(s)

W najprostszym przypadku możemy skonfigurować jeden węzeł, który będzie obsługiwał operacje odczytu i zapisu (MASTER), oraz jeden węzeł, który będzie obsługiwał tylko operacje odczytu.

 

 

Model ten można rozbudowywać o kolejne slave'y, co da się następnie zautomatyzować za pomocą Autoskalera.

 

 

1.1. Założenia

Do dalszych rozważań przyjmiemy, że posiadamy dwie instancje bazodanowe – db01, która pełnić będzie rolę mastera, oraz db02, którą będzie pełnić funkcję slave'a. Dla wygody wykorzystamy gotowe szablony z popularnym forkiem MySQL – Percona Server. Wszystkie instancje posiadają interfejs sieciowy z adresem publicznym do komunikacji z LB oraz interfejs w OPN, gdzie realizowana będzie replikacja.

Założymy też, że do komunikacji w ramach OPN wykorzystamy podsieć prywatną 192.168.0.0/16. Adresacja może być statyczna lub możemy wykorzystać wcześniej przygotowany serwer DHCP. Warto również dodać do firewalla reguły zezwalające na ruch do portu TCP 3306 wewnątrz OPN i na interfejsie publicznym z/do load balancera:

 

-A INPUT -i eth1 -p tcp --dport 3306 -j ACCEPT
-A INPUT -i eth0 -s 195.149.198.1 -p tcp --dport 3306 -j ACCEPT

 

Ostatecznym rezultatem naszych działań będzie następująca struktura, z punktu widzenia wykorzystanych usług.

 

 

1.2. Wstępna konfiguracja

Domyślna konfiguracja MySQL najczęściej nie jest wystarczająca do poprawnego zestawienia replikacji. Poniżej zamieszczamy przykładowy plik konfiguracyjny, który można wykorzystać (zapisujemy w /etc/mysql/conf.d/replication.cnf), może jednak zaistnieć potrzeba dostosowania go do swoich wymagań.

 

[mysqld] 
server-id = 1 
report-host = db01 
log-bin = db01-bin.log 

query-cache-size=0
query-cache-type=0

binlog-format = ROW 
binlog-row-image = minimal 
log-slave-updates = true 
gtid-mode = on 
enforce-gtid-consistency = true 
master-info-repository = TABLE 
relay-log-info-repository = TABLE 
sync-master-info = 1 
binlog-checksum = CRC32 
master-verify-checksum = 1 
slave-sql-verify-checksum = 1 
binlog-rows-query-log_events = 1 
report-port = 3306 
sync-binlog = 1 
innodb-flush-log-at-trx-commit = 1 

 

Powyższą konfigurację należy zastosować na wszystkich instancjach uczestniczących w replikacji. Należy pamiętać, że server-id i report-host muszą się różnić pomiędzy instancjami, aby replikacja działała poprawnie. Z tego powodu, jak również ze względu na przejrzystość konfiguracji, proponujemy stosowanie konwencji db${server-id} w wartościach zmiennych report-host i log-bin.

Trzeba też pamiętać o zmiennej server-uuid, która jest generowana automatycznie przez MySQL i domyślnie znajduje się w /var/lib/mysql/auto.cnf. Ten plik należy usunąć. Po jego usunięciu i ponownym uruchomieniu usługi MySQL zostanie on odtworzony z nową wartością server-uuid. Replikacja nie może działać poprawnie, kiedy dwie instancje serwera MySQL w niej uczestniczące mają tą samą wartość zmiennej server-uuid.

Po zapisaniu nowej konfiguracji, należy ponownie uruchomić usługę serwera MySQL.

 

service mysql restart

 

1.3. Zestawianie replikacji

Na instancji, która będzie pełnić funkcję mastera, tworzymy użytkownika, który będzie służył do realizacji replikacji.

 

@db01:
mysql> CREATE USER replicator;
mysql> GRANT REPLICATION SLAVE ON *.* TO replicator@'192.168.%' IDENTIFIED BY 'password';

 

Na instancji, która będzie pełnić funkcję slave'a, musimy ustawić dane instancji, która pełni funkcję mastera.

 

@db02:
mysql> CHANGE MASTER TO MASTER_HOST='192.168.0.1', MASTER_USER='replicator',
MASTER_PASSWORD='password', MASTER_AUTO_POSITION=1;

 

Aby rozpocząć replikację, na instancji db02 wydajemy następujące polecenie.

 

@db02:
mysql> START SLAVE;

 

W tym momencie replikacja powinna być zestawiona, co można sprawdzić, wydając na instancji db02 kolejne polecenie.

 

@db02:
mysql> SHOW SLAVE STATUS;

 

Dla poprawnie skonfigurowanej replikacji powinniśmy zauważyć następujący komunikat.

Waiting for master to send event oraz Slave has read all relay log; waiting for the slave I/O thread to update it, zależnie od tego, czy już zreplikowane zostały jakieś dane.

Na instancji db01 możemy sprawdzić stan mastera i listę slave'ów replikujących z niego dane za pomocą następujących poleceń.

 

@db01:
mysql> SHOW MASTER STATUS;
mysql> SHOW SLAVE HOSTS;


1.4. Replikacja semisynchroniczna

Jeśli wykonaliśmy poprawnie wszystkie kroki zaprezentowane do tej pory, posiadamy dwie instancje – db01 i db02 – z działającą replikacją. Jest to replikacja asynchroniczna, tzn. dane są zapisywane na instancji db01, po czym są przekazywane instancji db02 do zreplikowania, nie ma jednak pewności, że instancja db02 zdąży zreplikować dane przed awarią db01.

Aby zwiększyć niezawodność, możemy skorzystać z replikacji semisynchronicznej, wtedy commit zostaje potwierdzony przez mastera, tylko jeśli co najmniej jeden slave otrzyma kopię danych.

Aby włączyć replikację semisynchroniczną, należy zainstalować odpowiednie pluginy.

 

@db01:
mysql> INSTALL PLUGIN rpl_semi_sync_master SONAME 'semisync_master.so'; 
@db02:
mysql> INSTALL PLUGIN rpl_semi_sync_slave SONAME 'semisync_slave.so';

 

Następnie włączamy tryb replikacji semisynchronicznej.

 

@db01:
mysql> SET GLOBAL rpl_semi_sync_master_enabled = ON; 
@db02:
mysql> SET GLOBAL rpl_semi_sync_slave_enabled = ON; 
mysql> STOP SLAVE IO_THREAD; START SLAVE IO_THREAD;

 

Sprawdzamy status replikacji.

 

@db01:
mysql> SHOW STATUS LIKE 'Rpl_semi_sync_master_status'; 
+-----------------------------+-------+ 
| Variable_name               | Value | 
+-----------------------------+-------+ 
| Rpl_semi_sync_master_status | ON    | 
+-----------------------------+-------+ 
1 row in set (0.00 sec) 

mysql> SHOW STATUS LIKE 'Rpl_semi_sync_master_clients'; 
+------------------------------+-------+ 
| Variable_name                | Value | 
+------------------------------+-------+ 
| Rpl_semi_sync_master_clients | 1     | 
+------------------------------+-------+ 
1 row in set (0.00 sec) 

 

Jeśli zdecydujemy się stale korzystać z tego rodzaju replikacji, powinniśmy dodać odpowiednie opcje startowe do pliku konfiguracyjnego /etc/mysql/conf.d/replication.cnf.

 

@db01:
rpl_semi_sync_master_enabled = ON 
@db02:
rpl_semi_sync_slave_enabled = ON


1.5. Konfiguracja load balancera

Gdy posiadamy poprawnie skonfigurowaną replikację, potrzebujemy jeszcze mechanizmu, który sprawi, że kwerendy zmieniające strukturę bazy będą trafiać tylko do instancji MASTER, zapytania SELECT mogą natomiast trafiać do dowolnej z utworzonych instancji bazodanowych. Pomoże nam w tym load balancer Oktawave. Poniższy rysunek ukazuje, jaką rolę LB pełni w naszym rozwiązaniu.

 

 

Kontener z load balancerem konfigurujemy w następujący sposób.

 

 

Klikamy przycisk Dodaj kontener.

Wybieramy instancje, które znajdą się w kontenerze i zaznaczamy opcję Load balancer.

Wybieramy rodzaj usługi MySQL (3306), instancję master db01, a algorytm może być dowolny. Przy opcji Persystencja sesji wybieramy Brak persystencji. Warto zaznaczyć też opcję Healthcheck, dzięki której stan każdej z instancji uczestniczących w replikacji jest sprawdzany co sekundę, aby nie doprowadzić do skierowania zapytań do instancji nie działających prawidłowo. Jest to użyteczna funkcja, jednak ze względu na sposób, w jaki jest ona realizowana przez LB (nawiązanie połączenia TCP pod port 3306), wzbudza ona mechanizm MySQL odpowiedzialny za blokowanie hostów, które wykonują nieudane (wg. MySQL) próby połączeń. Aby przeciwdziałać temu zachowaniu i z powodzeniem używać LB do rozkładania ruchu do baz danych MySQL, należy okresowo wykonywać połączenia przez LB, które będą resetować licznik nieudanych prób połączeń per host, którego to wartość można zwiększyć za pomocą opcji max-connect-errors w /etc/mysql/my.cnf.

Gdy poprawnie skonfigurujemy kontener z load balancerem dla MySQL, otrzymamy adres load balancera oraz login i hasło do usługi MySQL. Te dane wykorzystamy w konfiguracji aplikacji, która będzie korzystać z naszego rozwiązania. Przykładowo, wpisy w pliku konfiguracyjnym Wordpressa (wp-config.php) wyglądałyby następująco:

 

// ** MySQL settings - You can get this info from your web host ** // 
/** The name of the database for WordPress */ 
define('DB_NAME', 'wordpress'); 

/** MySQL database username */ 
define('DB_USER', '00000686_Cs3p8BN'); 

/** MySQL database password */ 
define('DB_PASSWORD', 'random_password'); 

/** MySQL hostname */ 
define('DB_HOST', '195.149.198.75');

 

Aby zacząć korzystać z tej bazy, należy ją utworzyć i nadać odpowiednie uprawnienia.

 

@db01:
mysql> CREATE DATABASE wordpress;
Query OK, 1 row affected (0.00 sec)

mysql> GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, 
DROP ON `wordpress`.* TO '00000686_Cs3p8BN'@'195.149.198.1'
IDENTIFIED BY 'random_password';
Query OK, 0 rows affected (0.02 sec)

 

Dzięki temu że replikujemy wszystkie bazy, również uprawnienia do nich (znajdujące się w bazie mysql) zostaną zreplikowane do slave'ów.

Tym sposobem udało nam się uzyskać replikację baz danych dla naszego serwisu usługi oraz load balancing zapytań z wykorzystaniem LB Oktawave.


1.6. Zastosowanie Autoskalera horyzontalnego

Częstym zjawiskiem w serwisach WWW jest znacząca przewaga liczby zapytań do bazy danych nad liczbą komend modyfikujących jej zawartość. Aby zapewnić skalowalność liczby możliwych do obsłużenia zapytań, bazując na zaprezentowanym wcześniej rozwiązaniu, wykorzystamy Autoskaler horyzontalny w naszym kontenerze z load balancerem.

Musimy pamiętać, że instancjom pracującym w kontenerze trzeba zapewnić unikatowy adres IP do komunikacji w OPN oraz unikatowe wartości zmiennych MySQL. Musimy zatem odpowiednio przygotować instancję, która posłuży Autoskalerowi za szablon do klonowania nowych instancji w sposób, który nie będzie wymagał naszej ingerencji i będzie mógł przebiegać automatycznie.

Unikatowość adresacji IP w OPN możemy zapewnić, stosując serwer DHCP. Alternatywą jest zastosowanie adresacji link-local opisanej w RFC 3927. Jedyna instancja w naszym scenariuszu, której musimy zapewnić określony adres, to instancja db01, gdzie w /etc/network/interfaces ustawiamy statyczny adres dla interfejsu eth1 z podsieci przewidzianej w RFC, np. 169.254.1.1, a następnie restartujemy interfejs.

 

ifdown eth1; ifup eth1

 

Na instancji, która będzie szablonem do klonowania musimy zainstalować pakiet avahi-autoipd.

 

apt-get install avahi-autoipd


Następnie zamieniamy linijkę „iface eth1 inet dhcp” na „iface eth1 inet ipv4ll” w /etc/network/interfaces i restartujemy interfejs, po czym powinniśmy zobaczyć w wyniku polecenia ip addr show następującą pozycję.

 

inet 169.254.10.47/16 brd 169.254.255.255 scope link eth1:avahi 

 

W ten sposób zapewniliśmy unikatową adresację dla naszych instancji bazodanowych w OPN, nie stosując serwera DHCP.

W zasadzie mamy już unikatowy identyfikator, który możemy wykorzystać również do konfiguracji MySQL. Wygenerujemy teraz zmienne MySQL na podstawie adresów IP instancji za pomocą skryptu.

 

#!/usr/bin/env bash 

MYSQL_REPLICATION_CNF='/etc/mysql/conf.d/replication.cnf' 

SLAVE_IP=$(ip addr show eth1 | sed -e '/169.254/!d' -e 's/^.*inet //' -e 's/\/16.*$//') 
echo "SLAVE_IP: ${SLAVE_IP}" 
SLAVE_ID=$(echo ${SLAVE_IP} | sed -e 's/\.\([0-9][0-9]\)$/\.0\1/;s/\.\([0-9]\)$/\.00\1/'
 -e 's/169.254.//' -e 's/\.//' -e 's/^0*//')
echo "SLAVE_ID: ${SLAVE_ID}" 

sed -i "s/^server-id = .*/server-id = ${SLAVE_ID}/" $MYSQL_REPLICATION_CNF 
sed -i "s/^report-host = .*/report-host = db${SLAVE_ID}/" $MYSQL_REPLICATION_CNF 
sed -i "s/^log-bin = .*/log-bin = db${SLAVE_ID}-bin.log/" $MYSQL_REPLICATION_CNF 

# Force server-uuid regeneration 
rm /var/lib/mysql/auto.cnf 

 

Zapiszemy powyższy skrypt do /usr/local/bin/prepare_mysql_slave. Musi on zostać uruchomiony przed startem usługi MySQL, aby zostały wykorzystane poprawne, wygenerowane przez skrypt wartości zmiennych, dlatego też napiszemy skrypt uruchomieniowy, który zadba o to dla nas i zapiszemy go do /etc/init.d/prepare_mysql_slave.



#! /bin/sh 
### BEGIN INIT INFO 
# Provides:             prepare_mysql_slave 
# Required-Start: 
# Required-Stop:        mysql 
# Default-Start:        2 3 4 5 
# Default-Stop:         0 1 6 
# Short-Description:    Prepare MySQL (Percona) replication slave 
# Description: 
### END INIT INFO 

case "$1" in 
 start|"") 
 /usr/local/bin/prepare_mysql_slave 
 ;; 
 restart|reload|force-reload) 
 : 
 ;; 
 stop) 
 : 
 ;; 
 *) 
 : 
 ;; 
esac 
exit 0 

 

Musimy zadbać o to, aby obydwa skrypty były wykonywalne.

 

chmod +x /usr/local/bin/prepare_mysql_slave
chmod +x /etc/init.d/prepare_mysql_slave

 

Należy również dodać skrypt prepare_mysql_slave do odpowiednich runleveli, upewniając się, że zostanie on uruchomiony przed usługą MySQL.

 

update-rc.d prepare_mysql_slave start 15 2 3 4 5 . stop 15 0 1 6 . 
 Adding system startup for /etc/init.d/prepare_mysql_slave ... 
 /etc/rc0.d/K15prepare_mysql_slave -> ../init.d/prepare_mysql_slave 
 /etc/rc1.d/K15prepare_mysql_slave -> ../init.d/prepare_mysql_slave 
 /etc/rc6.d/K15prepare_mysql_slave -> ../init.d/prepare_mysql_slave 
 /etc/rc2.d/S15prepare_mysql_slave -> ../init.d/prepare_mysql_slave 
 /etc/rc3.d/S15prepare_mysql_slave -> ../init.d/prepare_mysql_slave 
 /etc/rc4.d/S15prepare_mysql_slave -> ../init.d/prepare_mysql_slave 
 /etc/rc5.d/S15prepare_mysql_slave -> ../init.d/prepare_mysql_slave 

 

Tak przygotowana instancja slave może funkcjonować jako źródło do klonowania nowych instancji w kontenerze. Po sklonowaniu instancji automatycznie dołączy ona do replikacji z unikatowym server-id.


2. Replikacja Multi-Master

Load balancer można wykorzystać też do zestawienia replikacji w modelu, gdzie kilka instancji jest jednocześnie wykorzystywanych do przeprowadzania operacji odczytu i zapisu. Rozważymy pierścień, w skład którego wchodzą trzy nody, zgodnie z zamieszczonym, przykładowym rysunkiem.






2.1. Założenia

Skorzystamy ze statycznej adresacji w OPN.

 

 db01mm: 10.0.0.1
 db02mm: 10.0.0.2
 db03mm: 10.0.0.3

 

Replikacja będzie przebiegać między parami instancji, zgodnie z następującym schematem.

 

 db01mm -> db02mm
 db02mm -> db03mm
 db03mm -> db01mm

 

Ze względu na związane z tym trudności konfiguracyjne i wiele możliwości wdrożenia takiego rozwiązania nie rozważamy w tym poradniku zastosowania Autoskalera horyzontalnego przy klasycznej replikacji Multi-Master.

 

2.2. Wstępna konfiguracja

Wykorzystamy plik konfiguracyjny replication.cnf z poprzedniego rozdziału. Ponieważ replikacja będzie odbywać się między parami instancji, jeśli chcemy korzystać z replikacji semisynchronicznej, musimy pamiętać o zainstalowaniu na każdym z hostów obydwu pluginów: rpl_semi_sync_master i rpl_semi_sync_slave oraz o ich konfiguracji.



2.3. Zestawienie replikacji

Wykonujemy kolejno następujące kroki.

 

@db01mm:
GRANT REPLICATION SLAVE ON *.* TO replicator@'10.0.0.2' IDENTIFIED BY 'random_password';

@db02mm:
GRANT REPLICATION SLAVE ON *.* TO replicator@'10.0.0.3' IDENTIFIED BY 'random_password';
CHANGE MASTER TO MASTER_HOST='10.0.0.1', MASTER_USER='replicator',
MASTER_PASSWORD='random_password', MASTER_AUTO_POSITION=1, IGNORE_SERVER_IDS=(2);
START SLAVE;

@db03mm:
GRANT REPLICATION SLAVE ON *.* TO replicator@'10.0.0.1' IDENTIFIED BY 'random_password';
CHANGE MASTER TO MASTER_HOST='10.0.0.2', MASTER_USER='replicator',
MASTER_PASSWORD='random_password', MASTER_AUTO_POSITION=1, IGNORE_SERVER_IDS=(3);
START SLAVE;

@db01mm:
CHANGE MASTER TO MASTER_HOST='10.0.0.3', MASTER_USER='replicator',
MASTER_PASSWORD='random_password', MASTER_AUTO_POSITION=1;
START SLAVE;

 

Stan replikacji sprawdzamy za pomocą poleceń znanych z rozdziału poświęconego replikacji w modelu Master-Slave.


2.4. Konfiguracja load balancera

W tym scenariuszu load balancer będzie rozkładał ruch równomiernie pomiędzy trzy instancje uczestniczące w replikacji.



W panelu Oktawave taki load balancer konfigurujemy następująco.



W efekcie uzyskujemy adres IP load balancera, który podajemy jako adres serwera bazodanowego w naszej aplikacji. Dane dostępowe do bazy ustalamy sami podczas tworzenia bazy i nadawania uprawnień użytkownikom na którejś z instancji uczestniczących w replikacji.



3. Alternatywa: wykorzystanie rozwiązania Percona XtraDB Cluster

Zamiast ręcznie zestawiać replikację w module Multi-Master, tak jak zostało to opisane w ustępach 2.2-2.3, możemy skorzystać z gotowego rozwiązania – Percona XtraDB Cluster, będącego dystrybucją Galera Cluster, które jest jeszcze prostsze w konfiguracji oraz łatwiejsze w utrzymaniu. W klastrze PXC istnieje również możliwość skorzystania z Autoskalera horyzontalnego.


3.1 Założenia

Minimalna zalecana konfiguracja PXC zakłada istnienie co najmniej trzech instancji, dlatego podstawę klastra stanowią instancje db01mm, db02mm i db03mm, utworzone z wykorzystaniem szablonu Percona OCI. Instancje połączone są za pomocą OPN i posiadają statyczne adresy IP, pozostałe instancje uzyskują natomiast adres za pomocą DHCP lub korzystają z adresów link-local. Powinniśmy również zezwolić na swobodną komunikację w OPN między instancjami, za pomocą odpowiedniej reguły iptables.

 

 -A INPUT -i eth1 -p tcp -m multiport --dports  3306,4444,4567,4568 -j ACCEPT


3.2 Wstępna konfiguracja

Aby zainstalować Percona XtraDB Cluster, wykonujemy następujące polecenia:

 

 apt-get update
 apt-get install percona-xtrabackup percona-xtradb-cluster-full-56

 

Zaczniemy od przygotowania pierwszej instancji w naszym klastrze. W tym celu wyłączamy usługę serwera MySQL, jeśli jest włączona.


service mysql stop

 

Poniżej przedstawiamy propozycję konfiguracji PXC, którą zapisujemy do pliku /etc/mysql/conf.d/galera.cnf.

 

[mysqld] 
binlog-format=ROW 
default_storage_engine=InnoDB 
innodb-autoinc-lock-mode=2 
query-cache-size=0 
query-cache-type=0 
wsrep-provider=/usr/lib/libgalera_smm.so 
wsrep-cluster-address=gcomm://169.254.1.1,169.254.1.2,169.254.1.3 
wsrep-node-address=169.254.1.1
wsrep-sst-method=xtrabackup-v2 
wsrep-cluster-name=GALERA 
wsrep-sst-auth="sst_service:random_password"

 

Musimy też pamiętać o ręcznej zmianie parametru wsrep-node-address na pozostałych węzłach ze statyczną adresacją. Parametr wsrep-sst-auth zawiera dane autoryzacyjne użytkownika bazy, który służy do realizacji replikacji danych w ramach klastra.


3.3 Inicjalizacja klastra

Gdy posiadamy już odpowiednio przygotowane instancje, możemy inicjalizować klaster na jednej z nich. W naszym przypadku będzie to db01mm.

 

# service mysql bootstrap-pxc
* Bootstrapping Percona XtraDB Cluster database server mysqld

 

Pierwszy węzeł PXC został pomyślnie zainicjalizowany. Logujemy się teraz do bazy i wydajemy następujące kwerendy, aby utworzyć użytkownika służącego do replikacji danych między węzłami klastra i nadać mu odpowiednie uprawnienia.

 

CREATE USER 'sst_service'@'localhost' IDENTIFIED BY 'random_password';
GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'sst_service'@'localhost';
FLUSH PRIVILEGES;


Na kolejnych węzłach musimy jedynie włączyć usługę serwera MySQL, wtedy węzeł automatycznie zsynchronizuje się z pozostałymi i dołączy do klastra.

 

# service mysql start
* Starting MySQL (Percona XtraDB Cluster) database server mysqld                                                                                                                * SST in progress, setting sleep higher mysqld 


3.4 Zastosowanie Autoskalera horyzontalnego

Podobnie jak w punkcje 1.6, musimy zadbać o prawidłową konfigurację każdej z instancji, która będzie należeć do klastra. W przypadku PXC konfiguracja sprowadza się w zasadzie do ustawienia adresu IP w pliku konfiguracyjnym. Jeśli korzystamy z adresów link-local, możemy posłużyć się rozwiązaniem analogicznym do opisanego w punkcie 1.6, stosując następujący skrypt.

 

#!/usr/bin/env bash 
MYSQL_GALERA_CNF='/etc/mysql/conf.d/galera.cnf' 
MEMBER_IP=$(ip addr show eth1 | sed -e '/169.254/!d' -e 's/^.*inet //' -e 's/\/16.*$//') 
sed -i "s/^wsrep-node-address=.*/wsrep-node-address=${MEMBER_IP}/" $MYSQL_GALERA_CNF 
# Force server-uuid regeneration 
rm /var/lib/mysql/auto.cnf

 

Przygotowaną w ten sposób instancję wybieramy jako źródło klonowania w Autoskalerze. W klastrze skonfigurowanym w ten sposób, instancje mogą być swobodnie dodawane a następnie usuwane przez Autoskaler wraz ze zmianami obciążenia serwisu/aplikacji.

(5 vote(s))
This article was helpful
This article was not helpful

Comments (0)
Post a new comment
 
 
Full Name:
Email:
Comments:
CAPTCHA Verification 
 
Please enter the text you see in the image into the textbox below. This is required to prevent automated registrations and form submissions.