Microsoft Azure wymaga, aby aplikacje korzystały z dwóch instancji w wielu centrach danych w celu osiągnięcia umowy SLA „wysokiej dostępności” i zapewnienia, że witryny nie ulegną rutynowej konserwacji. Mówią nawet, które pary centrów danych nigdy nie pójdą na konserwację jednocześnie.
Wszystko dobrze i dobrze, ale jak zrobiłbyś to w praktyce dla aplikacji takiej jak WordPress z bazą danych MySQL na tej samej maszynie wirtualnej? Nie jest mi obce równoważenie obciążenia między dwiema maszynami wirtualnymi, ale konfiguracja replikacji bazy danych mi umyka. Nie chcielibyśmy dwóch wersji danych, które mogłyby się zsynchronizować. Wydaje się, że replikacja MySQL wymaga konfiguracji master-slave, która nie zsynchronizuje zmian z master DB, jeśli użytkownik wyląduje na instancji slave.
Czy po prostu nie rozumiem tej koncepcji? Każda pomoc jest mile widziana!
Odpowiedzi:
Zła wiadomość: podstawowa baza Wordpress oparta na otwartym kodzie źródłowym ma kilka założeń na temat uruchamiania na jednym serwerze (wp-content, upload użytkowników i biblioteka multimediów, żeby wymienić tylko kilka)
Dobra wiadomość: prawie wszyscy dostawcy usług w chmurze (w tym platforma Azure) mają abstrakcje, które pozwalają obejść te ograniczenia projektowe.
Zasadniczo rozwiążesz następujące problemy:
/ - (10.0.0.1 - eth0) wp1.domain.com (10.0.1.1 - eth2) (Publiczny adres IP) wp.domain.com \ - (10.0.0.2 - eth1) wp2.domain.com (10.0.1.2 - eth3)Zarządzanie sesjami JEŻELI pozwalasz użytkownikom logować się na stronach. Jeśli tak, musisz upewnić się, gdy logują się na serwerze 1, że albo wszystkie ich przyszłe żądania zostaną skierowane do tego serwera (sesje trwałe), albo że nie ma znaczenia, do którego serwera mają dostęp, ponieważ sesjami zarządza się za pomocą innego mechanizmu (na przykład poprzez klastrowanie sesji Zend Server ).
Zarządzanie loginami administracyjnymi JEŚLI zezwalasz niektórym użytkownikom na logowanie się do zaplecza w celu zarządzania zawartością (podobnie jak powyżej).
Wybór systemu DB, który jest również wysoce dostępny. Nie ma sensu mieć dwóch serwerów frontonu, jeśli awaria bazy danych powoduje awarię całego systemu. Będziesz musiał wykorzystać replikację MySQL Master / Slave przez ClearDB lub zmodyfikować WordPress za pomocą wtyczki, aby wykorzystać SQL Server, aby móc korzystać z jego rodzimych systemów klastrowania . Oznacza to, że potrzebujesz co najmniej 4 maszyn wirtualnych, jeśli chcesz samodzielnie zarządzać warstwą bazy danych (2 x aplikacja i 2 x DB). Oto jak to może wyglądać:
/ - wp1.domain.com (10.0.1.1) \ --- / (10.0.1.3) db1.domain.com (10.0.2.3) \ wp.domain.com X | \ - wp2.domain.com (10.0.1.2) / --- \ (10.0.1.4) db2.domain.com (10.0.2.3) /UWAGA - aby zapewnić niezawodne przełączanie awaryjne i chronić bezpieczeństwo systemu, podsieć sieci THIRD jest zwykle używana do łączenia dwóch węzłów bazy danych ze sobą za pośrednictwem prywatnego kanału, który jest oddzielony od innych sieci komunikacyjnych, z którymi rozmawiają serwery aplikacji baza danych i serwery aplikacji używają do komunikacji ze światem zewnętrznym.
Włączanie puli połączeń w celu maksymalizacji wydajności i niezawodności połączeń z bazą danych serwera aplikacji.
Wykorzystanie wtyczki buforowania, takiej jak W3 Total Cache lub Super Cache, aby zminimalizować obciążenie serwerów frontonu.
Poniższe przewodniki zawierają szczegółowe informacje na temat sposobu rozwiązania każdego z powyższych problemów. Istnieje kilka sposobów obsługi każdego z nich na platformie Azure, więc to Ty decydujesz, jak chcesz zaatakować każde wyzwanie, a następnie poradzić sobie z ograniczeniami, które każdy z tych wyborów nakłada podczas pracy na stosie.
źródło