Piszki Lab

Analiza przypadku w języku przodków…

Prowadzenie bloga, część 4: Zwrotna synchronizacja z VPS do NAS.

| 0 comments

W jednym z ostatnich postów opisałem migrację bloga na zewnętrzny serwer VPS. Teraz opiszę jak zrobić zwrotną synchronizację na naszego Synology. Można się zapytać, po co? Odpowiedź jest prosta, VPS jako usługa chmurowa może zniknąć tak jak się pojawiła (wraz z naszymi danymi). Przyczyn może być wiele, od ataku hakera po bankructwo dostawcy (śledzicie takie informacje?). Dlatego backup zwrotny to podstawa, w przypadku awarii VPS wystarczy zmiana adresu bloga w serwerze DNS i strona wraca do życia (na naszym NAS)! W drugą stronę też to działa, jak popsujemy VPS to zawsze mamy aktualną kopię z której możemy odtworzyć stronę.

backup

Cała procedura jest bardzo prosta.

W pierwszym kroku musimy zestawić tunel VPN pomiędzy naszym VPS a NAS. Instalujemy i uruchamiamy na Synology  VPN Server. Teraz wybieramy typ serwera. Ja zdecydowałem się na OpenVPN, w przypadku Linuksa jest to chyba najprostsza i najmniej kłopotliwa metoda. Konfiguracja po stronie Synology jest bardzo prosta, najpierw włączamy usługę OpenVPN z odpowiednimi ustawieniami (adresacja sieci (10.10.10.0) może być dowolna, inna niż lokalna dla DiskStation):

vpn1

 

Teraz w ustawieniach zmieniamy nazwę interfejsu z eth na LAN (lub jeśli NAS pracuje jako WiFi AP to opisany będzie jako „Internet”):

vnp2

W moim przypadku NAS jest wystawiony bezpośrednio do Internetu (DMZ), w takim przypadku firewall to podstawa. Jako że nie przewiduję połączeń do serwera VPN innych niż z VPS, dodałem tylko jedną regułę otwierającą odpowiedni port tylko dla serwera VPS. Zawsze kilka ataków mniej. Chodź jak widać na obrazku powyżej, VPN Server jest zsynchronizowany z usługą blokowania (fail2ban). Na samym dole widać też regułę otwierającą tylko wybrane usługi (Syslog, Rsync, MariaDB) dla adresacji 10.10.10.0 (strzeżonego etc. etc., sami wiecie), ale nie jest konieczna, poziom zaufania sami ustawiacie.

vpn3

Przechodzimy teraz na stronę klienta, instalacja i uruchomienie OpenVPN na CentOS 7 jest bardzo proste, wydajemy polecenie yum install openvpn (po wcześniejszym zainstalowaniu repozytorium EPEL z Fedory). Tak zainstalowany serwer nie tworzy plików konfiguracyjnych, te możemy wyeksportować z DiskStation lub użyć tego:

[root@vps openvpn]# cat openvpn.conf
dev tun
tls-client

remote nas.piszki.pl 1194

pull
proto udp
script-security 2

ca /etc/openvpn/ca.crt
comp-lzo
reneg-sec 0

auth-user-pass /etc/openvpn/login.conf

#tls-auth /etc/openvpn/ta.key 1
[root@vps openvpn]#

Bardzo ważny jest certyfikat CA za pomocą którego będziemy weryfikować naszego NASa. Ja używam certyfikatu wygenerowanego w RapidSSL. Ważne, aby plik ca.crt zawierał cały łańcuch urzędów certyfikacyjnych (chain). W przypadku RapidSSL nie jest to takie oczywiste.

Następnie ręcznie sprawdzamy czy połączenie zapina się poprawnie:

[root@vps openvpn]# /usr/sbin/openvpn –cd /etc/openvpn –config openvpn.conf
Sat Oct 18 12:43:43 2014 OpenVPN 2.3.2 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [eurephia] [MH] [IPv6] built on Feb 14 2014
Sat Oct 18 12:43:43 2014 WARNING: No server certificate verification method has been enabled.  See
http://openvpn.net/howto.html#mitm for more info.
Sat Oct 18 12:43:43 2014 UDPv4 link local (bound): [undef]
Sat Oct 18 12:43:43 2014 UDPv4 link remote: [AF_INET]89.74.89.55:1194
Sat Oct 18 12:43:43 2014 WARNING: this configuration may cache passwords in memory — use the auth-nocache option to prevent this
Sat Oct 18 12:43:44 2014 [nas.piszki.pl] Peer Connection Initiated with [AF_INET]89.74.89.55:1194
Sat Oct 18 12:43:46 2014 TUN/TAP device tun0 opened
Sat Oct 18 12:43:46 2014 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Oct 18 12:43:46 2014 /usr/sbin/ip link set dev tun0 up mtu 1500
Sat Oct 18 12:43:46 2014 /usr/sbin/ip addr add dev tun0 local 10.10.10.6 peer 10.10.10.5
Sat Oct 18 12:43:46 2014 Initialization Sequence Completed

Komunikat “server certificate verification…” dotyczy dotakowej opcji tls-auth która domyślnie nie jest włączona w Synology (i ja jej nie konfigurowałem ze względu na zaufane połączenie punkt punkt poprzez firewall). Jeśli wszystko gra, wydajemy kolejne polecenia (przy założeniu, że plik konfiguracyjny nazywa się openvpn.conf):

systemctl enable openvpn@openvpn.service

systemctl start openvpn@openvpn.service

Możemy sprawdzić status usługi:

[root@vps log]# systemctl status openvpn@openvpn.service
openvpn@openvpn.service – OpenVPN Robust And Highly Flexible Tunneling Application On openvpn
Loaded: loaded (/usr/lib/systemd/system/openvpn@.service; enabled)
Active: active (running) since Sat 2014-10-18 12:46:30 CEST; 2min 12s ago
Main PID: 28025 (openvpn)
CGroup: /system.slice/system-openvpn.slice/openvpn@openvpn.service
└─28025 /usr/sbin/openvpn –daemon –writepid /var/run/openvpn/openvpn.pid –cd /etc/openvpn/ –config openvpn.conf

Oct 18 12:46:30 vps.piszki.pl openvpn[28025]: UDPv4 link local (bound): [undef]
Oct 18 12:46:30 vps.piszki.pl openvpn[28025]: UDPv4 link remote: [AF_INET]89.74.89.55:1194
Oct 18 12:46:30 vps.piszki.pl systemd[1]: Started OpenVPN Robust And Highly Flexible Tunneling Application On openvpn.
Oct 18 12:46:30 vps.piszki.pl openvpn[28025]: WARNING: this configuration may cache passwords in memory — use the auth-nocache option to prevent this
Oct 18 12:46:31 vps.piszki.pl openvpn[28025]: [nas.piszki.pl] Peer Connection Initiated with [AF_INET]89.74.89.55:1194
Oct 18 12:46:33 vps.piszki.pl openvpn[28025]: TUN/TAP device tun0 opened
Oct 18 12:46:33 vps.piszki.pl openvpn[28025]: do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Oct 18 12:46:33 vps.piszki.pl openvpn[28025]: /usr/sbin/ip link set dev tun0 up mtu 1500
Oct 18 12:46:33 vps.piszki.pl openvpn[28025]: /usr/sbin/ip addr add dev tun0 local 10.10.10.6 peer 10.10.10.5
Oct 18 12:46:33 vps.piszki.pl openvpn[28025]: Initialization Sequence Completed
[root@vps log]# cd

Tunel działa, przystępujemy do synchronizacji danych. W przypadku plików użyjemy rsync, a w przypadku MariaDB zapniemy prawdziwy, geograficzny klaster online. Oczywiście nie będziemy tutaj zestawiać klastra typu Galera, w zupełności wystarczy prosta replikacja danych poprzez tunel VPN w schemacie Master—>Slave. Zaczynamy od MariaDB na serwerze VPS, będzie ona pełniła rolę “master”. Do naszego pliku konfiguracyjnego dodajemy kilka linijek:

log-basename=master
log-bin
binlog-format=mixed
server_id=1
sync_binlog = 1
expire_logs_days = 90
max_binlog_size = 1G

Następnie musimy otworzyć port na firewallu, tak aby można było się podłączyć z DiskStation do MariaDB. Jestem zwolennikiem możliwie prostych rozwiązań, dlatego na VPS używam simple-firewall. Nie można w nim robić skomplikowanych reguł, dlatego po prostu dodałem interfejs “tun+” do listy zaufanych (adresacja 10.10.10.0 nie jest widoczna z Internetu):

vpn4

Restartujemy MariaDB na VPS i poleceniem telnet sprawdzamy czy istnieje komunikacja z naszego NAS:

vpn5

Odpowiedział serwer MariaDB, połączenie działa poprawnie. Teraz możemy dodać użytkownika slave z uprawnieniami do replikacji na serwerze Master (VPS).

vpn6

Odświeżamy uprawnienia:

vpn7

I po stronie Synology sprawdzamy czy można się podłączyć:

vpn8

Działa! Teraz musimy wykonać synchronizację baz danych z ustawieniem punktu od którego serwer Slave będzie odbierał dane. Najbezpieczniej byłoby odciąć na chwilę dostęp z Internetu do naszego Bloga tak, aby zmian było jak najmniej. Ale z drugiej strony to nie system produkcyjny w korporacji, wystarczy chwilowe ustawienie LOCK na tabelach. Na serwerze Master (VPS) wydajemy polecenia:

vpn9

Mamy założonego LOCK a pozycja w logu to 9780 (od niej zaczniemy synchronizację). Teraz eksportujemy wszystkie bazy danych i zdejmujemy blokadę:

vpn10

Cała procedura trwa poniżej minuty, na blogu raczej nikt tego nie odczuje. Teraz kopiujemy plik z bazami danych na DiskStation:

vpn11

Rekonfigurujemy MariaDB na Synology DSM 5.0 tak aby działał w trybie Slave.

Do pliku: /var/packages/MariaDB/etc/my.cnf dopisujemy następujące linijki :

[mysqld]

server-id = 2
log-bin
sync_binlog = 1

Następnie restartujemy MariaDB z poziomu Synology DSM. Należy też po każdym upgrade MariaDB przez Synology (włączając w to też upgrade DSM) sprawdzić czy nasze zmiany nie zostały usunięte! Teraz importujemy dane (to polecenie nadpisze wszystkie istniejące lokalnie bazy danych!):

vpn12

Konfigurujemy serwer Slave tak, aby wiedział skąd ma pobierać dane i od którego momentu:

vpn13

Na koniec możemy sprawdzić, czy replikacja działa poprawnie:

vpn14

Działa (Yes, Yes)! Jeśli będzie “No” to zwiększamy uprawnienia użytkownika slave (grant RELOAD,SUPER,REPLICATION CLIENT on …), można to też zrobić pro forma. Możemy teraz zająć się replikacją plików pomiędzy VPS a NAS. Ten temat jest na szczęście dużo prostszy, wystarczy na naszym serwerze VPS doinstalować (jeśli jeszcze nie mamy), polecenie rsync. Po stronie naszego Synology wystarczy wykonać jeden krok, uruchamiamy “Kopia zapasowa i replikacja” i włączamy usługi sieciowej kopii zapasowej (opcja “dostosowana konfiguracja” nie jest konieczna):

vpn

Teraz wracamy na VPS, polecenie rsync wymaga podania loginu i hasła gdy synchronizujemy dane na zdalny serwer (w naszym przypadku przez tunel VPN). My zautomatyzujemy cały proces, ręczne podawanie hasła nie wchodzi w grę, zaczniemy zatem od przygotowania autentykacji kluczami ssh pomiędzy naszymi serwerami. Zaczynamy od wygenerowania klucza publicznego na serwerze VPS:

vpn01

Zawartość klucza id_rsa_pub wklejamy do pliku /root/.ssh/authorized_keys na naszym Synology:

vpn02

W tej chwili jesteśmy gotowi do synchronizacji, właściwe polecenie wygląda tak (oczywiście synchronizowane katalogi zależą tylko od Was):

vpn03

Ostatecznie pozostaje nam (w przypadku CentOS 7) stworzenie pliku z ww. poleceniem i wrzuceniem go do katalogu /etc/cron.daily Uśmiech

A teraz bonus! W takiej konfiguracji możemy wykonać backup odwrotny, czyli zgrać konfigurację Synology na serwer VPS poprzez rsync. Po stronie VPS nie wymaga to żadnej konfiguracji, wystarczy założyć katalog (/bak) na pliki z Synology. Na DiskStation uruchamiamy program “Kopia zapasowa i replikacja” i w sekcji “Miejsce docelowe…” stworzyć odpowiednie połączenie:

vpn15

A w sekcji “Kopia zapasowa” właściwą kopię:

vpn16

Działa to rewelacyjnie, ale pamiętajcie: Prawdziwy mężczyzna backupu nie robi! Puszczam oczko

Hmm, kobieta tym bardziej? Puszczam oczko

Ehh… Uśmiech

 

EDIT 2014.11.14:

W dniu dzisiejszym serwerownia Amsterdam-2 którą wybrałem na leże mojego VPS (a adresację mam rruską) zaliczyła awarię. Przez 1.5h mój silos miał wywaloną sieć. Tak się złożyło, że akurat siedziałem przy laptopie i dłubałem w konsoli. Awarię zauważyłem w tej samej chwili w której wystąpiła. Po kilku nerwowych ruchach stwierdziłem, że serwerek jest martwy. Interfejs działa, konsola nie działa, nic się nie pinga.

ams2

Wykonałem pierwsze, pełne przełączenie pomiędzy ośrodkami (ależ to brzmi!). I idea okazała się słuszna, całość ruszyła bez problemu! Kopia okazała się w pełni zsynchronizowana. Po usunięciu awarii przywróciłem właściwe rekordy DNS i całość wskoczyła na stare tory Uśmiech

Oceń ten artykuł:
[Głosów:1    Średnia:5/5]

Dodaj komentarz

Required fields are marked *.


.

Podobał się wpis? Wesprzyj Piszki Lab, kliknij w reklamę! :-)

.