V předchozích blozích (část 1 a část 2) jsme diskutovali o tom, jak migrovat data RDS do instance EC2. Během tohoto procesu se nám podařilo přesunout naše data z RDS, ale stále běžíme na AWS. Pokud byste chtěli svá data úplně přesunout mimo Amazon Web Services, čeká vás ještě trochu práce. V dnešním příspěvku na blogu vám ukážeme, jak to lze udělat.
Úvod do životního prostředí
Prostředí, se kterým budeme pracovat, je velmi podobné tomu, se kterým jsme skončili v našem posledním příspěvku v seriálu. Jediný rozdíl je v tom, že nedošlo k žádnému přerušení, protože instanci EC2 použijeme jako mezikrok v procesu přechodu z AWS.
Počáteční nastavení infrastrukturyAkční plán
Související zdroje MySQL v cloudu – Online migrace z Amazon RDS do instance EC2 (část 1) MySQL v cloudu – Online migrace z Amazon RDS na váš vlastní server (část 2) MySQL v cloudu – výhody a nevýhody Amazon RDSV předchozím blogu jsme nejprve migrovali naše data z RDS do instance EC2, ke které máme plný přístup. Protože na naší instanci EC2 již běží MySQL, máme na výběr více možností, jak zkopírovat naše data do jiného cloudu. DigitalOcean se zde používá pouze pro demo účely, proces, který popisujeme níže, lze použít k migraci na jakéhokoli jiného poskytovatele hostingu nebo cloudu. Potřebovali byste přímý přístup k instancím VPS. V tomto procesu použijeme xtrabackup ke zkopírování dat (i když je naprosto v pořádku použít jakýkoli jiný způsob binárního přenosu). Potřebovali bychom připravit bezpečné spojení mezi AWS a DigitalOcean. Jakmile to uděláme, nastavíme replikaci z instance EC2 do kapky DigitalOcean. Dalším krokem by bylo provedení vyříznutí a přesunutí aplikací, ale tím se zde nebudeme zabývat.
Rozhodnutí o způsobu připojení
Amazon Web Services vám umožňuje vybrat si z mnoha různých způsobů, jak vytvořit připojení k externím sítím. Pokud máte hardwarové zařízení, které podporuje připojení VPN, můžete jej použít k vytvoření připojení VPN mezi vaším VPC v AWS a vaší místní infrastrukturou. Pokud vám váš poskytovatel sítě nabízí peeringové připojení se sítí AWS a máte směrovač BGP, můžete získat přímé připojení VLAN mezi vaší sítí a AWS prostřednictvím AWS Direct Connect. Pokud máte více izolovaných sítí, můžete je propojit s Amazonem pomocí AWS VPN CloudHub. A konečně, protože instance EC2 můžete spravovat vy, můžete také nastavit VPN mezi touto instancí EC2 a vaší místní sítí pomocí softwarových řešení, jako je OpenVPN.
Protože mluvíme o databázích, můžete se také rozhodnout nastavit replikaci SSL mezi MySQL na EC2 (master) a slave běžícím na DigitalOcean. - Stále musíme přijít na to, jak provést počáteční přenos dat do slave - jedním řešením by mohlo být tarovat výstup xtrabackup, zašifrovat tento soubor a buď jej poslat přes WAN (rsync) nebo nahrát do S3 bucketu a poté jej stáhnout odtamtud. Můžete se také spolehnout na šifrování SSH a jednoduše scp (nebo dokonce rsync, pomocí SSH) data do nového umístění.
Na výběr je mnoho možností. Použijeme však jiné řešení – zavedeme tunel SSH mezi instancí EC2 a naším dropletem DigitalOcean, abychom vytvořili bezpečný kanál, který budeme používat k replikaci dat. Počáteční přenos bude proveden pomocí rsync přes připojení SSH.
Několik nines DevOps Průvodce správou databázíZjistěte, co potřebujete vědět k automatizaci a správě vašich databází s otevřeným zdrojovým kódemStáhněte si zdarmaKopírování dat do DigitalOcean
Jakmile na instanci DigitalOcean zprovozníme MySQL 5.7, musíme provést zálohu instance EC2 a poté ji přenést do DO. Technicky by mělo být možné provádět přímé streamování dat xtrabackup mezi uzly, ale nemůžeme to příliš doporučit. Odkazy WAN mohou být nespolehlivé a bylo by lepší udělat zálohu lokálně a poté použít rsync s jeho schopností opakovat přenos, kdykoli něco není v pořádku.
Nejprve si udělejme zálohu na naší instanci EC2:
[email protected]:~# innobackupex --user=tpcc --password=tpccpass /tmp/backup
Jakmile bude připraven, musíme jej přenést do sítě DigitalOcean. Abychom to provedli bezpečným způsobem, vytvoříme nového uživatele na dropletu DO, vygenerujeme klíč SSH a pomocí tohoto uživatele zkopírujeme data. Samozřejmě můžete použít i kteréhokoli ze stávajících uživatelů, není nutné vytvářet nového. Pojďme tedy přidat nového uživatele. Existuje mnoho způsobů, jak to udělat, my použijeme příkaz „adduser“.
[email protected]:~# adduser rdscopy
Adding user `rdscopy' ...
Adding new group `rdscopy' (1001) ...
Adding new user `rdscopy' (1001) with group `rdscopy' ...
Creating home directory `/home/rdscopy' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for rdscopy
Enter the new value, or press ENTER for the default
Full Name []:
Room Number []:
Work Phone []:
Home Phone []:
Other []:
Is the information correct? [Y/n] y
Nyní je čas vygenerovat pár ssh klíčů pro připojení:
[email protected]:~# ssh-keygen -C 'rdscopy' -f id_rsa_rdscopy -t rsa -b 4096
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa_rdscopy.
Your public key has been saved in id_rsa_rdscopy.pub.
The key fingerprint is:
3a:b0:d2:80:5b:b8:60:1b:17:58:bd:8e:74:c9:56:b3 rdscopy
The key's randomart image is:
+--[ RSA 4096]----+
| .. |
| o . o |
| . .. + o |
| o ..* E |
|+o+.* S |
|o+++ + . |
|o.. o o |
| . . |
| |
+-----------------+
Když máme klíč SSH, musíme jej nastavit na naší kapce Digital Ocean. Potřebujeme vytvořit adresář .ssh a vytvořit soubor autorizovaných klíčů se správnými přístupovými oprávněními.
[email protected]:~# mkdir /home/rdscopy/.ssh
[email protected]:~# cat id_rsa_rdscopy.pub > /home/rdscopy/.ssh/authorized_keys
[email protected]:~# chown rdscopy.rdscopy /home/rdscopy/.ssh/authorized_keys
[email protected]:~# chmod 600 /home/rdscopy/.ssh/authorized_keys
Poté musíme zkopírovat náš soukromý klíč do instance EC2. Když jsme s tím připraveni, můžeme zkopírovat naše data. Jak jsme již zmínili, použijeme k tomu rsync – ten nám umožní restartovat přenos, pokud se proces z jakéhokoli důvodu přeruší. V kombinaci s SSH jsme vytvořili bezpečnou a robustní metodu kopírování dat přes WAN. Začněme rsync na hostiteli EC2:
[email protected]:~# rsync -avz -e "ssh -i id_rsa_rdscopy -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" --progress /tmp/backup/2017-02-20_16-34-18/ [email protected]:/home/rdscopy
Po chvíli, která bude záviset na množství dat a rychlosti přenosu, by měla být naše zálohovaná data dostupná na kapce DigitalOcean. To znamená, že je čas jej připravit použitím InnoDB redo logs a následným zkopírováním zpět do datového adresáře MySQL. K tomu potřebujeme zastavit MySQL, odstranit aktuální datový adresář, zkopírovat soubory zpět pomocí innobackupex nebo ručně a nakonec ověřit, že vlastník a skupina pro nové soubory jsou nastaveny na mysql:
[email protected]:~# innobackupex --apply-log /home/rdscopy/
[email protected]:~# service mysql stop
[email protected]:~# rm -rf /var/lib/mysql/*
[email protected]:~# innobackupex --copy-back /home/rdscopy/
[email protected]:~# chown -R mysql.mysql /var/lib/mysql
Než spustíme MySQL, musíme se také ujistit, že server_id a UUID jsou různé. První lze upravit v my.cnf, druhý lze zajistit:
[email protected]:~# rm /var/lib/mysql/auto.cnf
Nyní můžeme spustit MySQL:
[email protected]:~# service mysql start
Nastavení replikace
Jsme připraveni nastavit replikaci mezi EC2 a DO, ale nejprve musíme nastavit ssh tunel – vytvoříme další ssh klíč pro uživatele ubuntu na instanci EC2 a zkopírujeme ho do instance DO. Poté pomocí uživatele ubuntu vytvoříme tunel, který použijeme pro replikaci.
Začněme vytvořením nového klíče ssh:
[email protected]:~# ssh-keygen -C 'tunnel' -f id_rsa_tunnel -t rsa -b 4096
Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa_tunnel.
Your public key has been saved in id_rsa_tunnel.pub.
The key fingerprint is:
c4:44:79:39:9c:c6:ce:45:bb:13:e5:6f:c5:d9:8c:14 tunnel
The key's randomart image is:
+--[ RSA 4096]----+
| .o+ +. E. |
| o. O .= +o|
| o= oo o.=|
| . o o ..|
| S o o|
| . . |
| |
| |
| |
+-----------------+
Další krok – musíme přidat náš veřejný klíč do souboru author_keys na instanci EC2, ke kterému se připojíme z DigitalOcean a vytvoříme tunel.
[email protected]:~# cat id_rsa_tunnel.pub >> /home/ubuntu/.ssh/authorized_keys
Potřebujeme také soukromý klíč, který se má přenést do dropletu DO. Lze to udělat mnoha způsoby, ale my použijeme secure scp pomocí uživatele a klíče rdscopy, které jsme vytvořili dříve:
[email protected]:~# scp -i id_rsa_rdscopy id_rsa_tunnel [email protected]:/home/rdscopy
id_rsa_tunnel 100% 3247 3.2KB/s 00:00
To je vše, co potřebujeme – nyní můžeme vytvořit tunel SSH. Chceme, aby byl dostupný neustále, takže pro něj použijeme relaci obrazovky.
[email protected]:~# screen -S tunnel
[email protected]:~# ssh -L 3307:localhost:3306 [email protected] -i /home/rdscopy/id_rsa_tunnel
Zde jsme provedli otevření tunelu SSH mezi localhostem, portem 3307 a vzdáleným hostitelem, 54.224.107.6, portem 3306 pomocí uživatele „ubuntu“ a klíče umístěného v /home/rdscopy/id_rsa_tunnel. Odpojte relaci obrazovky a vzdálený hostitel by měl být dostupný přes 127.0.0.1:3307.
K nastavení replikace ještě musíme přidat n uživatele, kterého použijeme pro připojení k MySQL na EC2. Vytvoříme jej na hostiteli EC2 a jako hostitele použijeme ‚127.0.0.1‘ – připojení přes tunel SSH budou vypadat, jako by pocházela z localhost:
mysql> CREATE USER [email protected] IDENTIFIED BY 'rds_rpl_pass';
Query OK, 0 rows affected (0.00 sec)
mysql> GRANT REPLICATION SLAVE ON *.* TO [email protected];
Query OK, 0 rows affected (0.00 sec)
Vše je připraveno k nastavení replikace, nyní je čas sledovat tradiční proces vytváření slave zařízení na základě dat xtrabackup. Potřebujeme použít data z xtrabackup_binlog_info k identifikaci hlavní pozice v době zálohování. Tuto pozici chceme použít v našem příkazu CHANGE MASTER TO …. Podívejme se na obsah souboru xtrabackup_binlog_info:
[email protected]:~# cat /home/rdscopy/xtrabackup_binlog_info
binlog.000052 896957365
Toto je binární soubor protokolu a pozice, které použijeme v našem CHANGE MASTER TO:
[email protected]:~# mysql -u root -ppass
mysql> CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=3307, MASTER_USER='rds_rpl', MASTER_PASSWORD='rds_rpl_pass', MASTER_LOG_FILE='binlog.000052', MASTER_LOG_POS=896957365; START SLAVE;
To je ono - replikace by nyní měla být spuštěna a náš DigitalOcean slave by měl replikaci dohánět. Jakmile to dožene, naše databázová vrstva je připravena na přechod. Obvykle se samozřejmě jedná o více než jen jeden uzel – s největší pravděpodobností budete muset na DO nastavit více podřízených jednotek, než bude infrastruktura připravena zvládnout produkční provoz.
Samotný přechod je jiné téma – budete muset vymyslet plán, jak minimalizovat prostoje. Obecně platí, že provoz by se měl přesunout ze starého do nového umístění, ale způsob, jakým by to mělo být provedeno, závisí především na vašem prostředí. Může to být cokoli od jednoduché změny v záznamu DNS až po složité skripty, které stahují všechny spouštěče ve správném pořadí, aby přesměrovaly provoz. Bez ohledu na to je vaše databáze nyní již v novém umístění a je připravena obsluhovat požadavky.