Jak uruchomić WordPress na 2 maszynach wirtualnych w celu zapewnienia wysokiej dostępności

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!

— Yaron
źródło

Dlaczego miałbyś hostować WordPress na platformie Azure? Istnieje lepszy i tańszy hosting dla WordPress. Na przykład Digital Ocean.

— Alexus,

Alexus, tutaj nie ma to większego znaczenia, ale mamy dość duży stos w infrastrukturze platformy Azure, którego WordPress jest tylko jednym składnikiem. Azure to fantastyczna platforma i jesteśmy z niej bardzo zadowoleni.

— Yaron

gotcha. Musisz robić to, co musisz robić :) Lubię też platformę Azure dla większości moich rzeczy .NET, ale zawsze hostowałem osobno witryny WP.

— Alexus

Yaron, czy poniższa odpowiedź była dla ciebie pomocna? Do tej pory otrzymano 3 głosy poparcia, chciałem tylko sprawdzić, czy brakuje jakiegoś ważnego pojęcia, abym mógł go zaktualizować, aby rozwiązać ten przypadek w konkretnym przypadku.

— Bryan „BJ” Hoffpauir Jr.

Bardzo dziękuję za dokładną odpowiedź @ Bryan'BJ'Hoffpauir i przepraszam, że nie miałem czasu, aby spróbować wykonać instrukcje, aby sprawdzić, czy działają one z naszą implementacją. Zaznaczam odpowiedź jako poprawną i skontaktuję się ponownie, jeśli napotkam jakiekolwiek problemy. Dzięki jeszcze raz!!

— Yaron,

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:

Równoważenie obciążenia ruchu między dwoma (lub więcej) „frontowymi” serwerami / aplikacjami Wordpress. Nie jest to trudne, ponieważ Wordpress jest NAJBARDZIEJ bezpaństwowy, chyba że pozwalasz użytkownikom na logowanie się do stron. Odbywa się to za pomocą kombinacji DNS i Load Balancers. Będziesz potrzebować wsparcia dla 2 adresów IP dla swoich serwerów aplikacji - 1 zestaw połączy się z podsiecią, którą można routować przez Internet (choć, mam nadzieję, będzie chroniony przez zaporę ogniową nie wymienioną poniżej), a pozostałe dwa będą w INNEJ podsieci, która jest odizolowana od druga sieć i zawiera instancje serwera bazy danych, ale podstawowy zarys jest taki:

                     / - (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.

— Bryan „BJ” Hoffpauir Jr.
źródło