DevOps for Updating and Optimizing Infrastructure (physical servers)

Wstępne zadanie techniczne dla DevOps

Pełne zadanie zostanie opracowane po konsultacji wykonawcy prac z technicznym liderem zespołu, ponieważ nie ma pewności co do niuansów, optymalnej liczby serwerów i ich potencjalnej konfiguracji.

Tło projektu

Używane są serwery fizyczne. Ich użycie planowane jest również w przyszłości, ponieważ analogiczne konfiguracje w dostawcach chmurowych będą znacznie droższe i, moim zdaniem, będą wymagać bardziej skomplikowanej konfiguracji. W naszym modelu okazało się bardziej opłacalne zamówienie jednego dużego i potężnego serwera, który zazwyczaj obsługuje codziennie około 2 milionów unikalnych odwiedzin i jednocześnie, zakładam, że ma pięciokrotny zapas mocy oraz dodatkowy serwer zapasowy w innym centrum danych, na który można przełączyć się w przypadku krytycznych awarii.

Problemy w istniejącym rozwiązaniu:

- Obecny serwer wymaga wymiany dysków SSD, które od pewnego czasu wyświetlają ostrzeżenie (właściwie to spowodowało to poszukiwanie DevOps). Rozważamy opcję tymczasowego przełączenia na kopię zapasową, wymiany dysków i pełnej instalacji nowego dystrybucji oraz całej aplikacji, lub zakupu nowych 2-3 serwerów, rozwinięcia pełnej architektury na nich i przekierowania ruchu (zaletą drugiej ścieżki jest wygoda, kontrola, możliwość testów i możliwość wyboru szybszych dysków i procesora, wada - za zakup nowych serwerów trzeba będzie dopłacić za instalację). Jako alternatywę - rozwinięcie architektury na jednym lub dwóch nowych serwerach, przekierowanie ruchu na nie, a następnie zaktualizowanie dysków na starym serwerze i wykorzystanie go jako zapasowego z replikacją MySQL.

- Na serwerze używana jest przestarzała wersja CentOS 7. Być może warto zaktualizować się do Rocky/Alma lub nawet rozważyć przejście na Debian (to pytanie wchodzi w zakres konsultacji).

- ISPManager pozostał z historycznych powodów i teraz bardziej przeszkadza niż pomaga w zarządzaniu. Takie panele kontrolne praktycznie straciły sens - konfigurację będziemy wykonywać za pomocą Nginx.

- Docker jest używany tylko dla MySQL, pozostałe aplikacje instalowano za pomocą yum ze wszystkimi wadami takiego rozwiązania (niespodziewane aktualizacje, niemożność utworzenia zarządzanego środowiska, konieczność konfigurowania każdej aplikacji).

- Na serwerze znajdują się co najmniej dwa powiązane projekty i jeden pośrednio powiązany. Najprawdopodobniej warto trzymać je na jednym serwerze, ale można rozważyć opcję z kilkoma serwerami, jeśli to przyniesie określone korzyści.

- Obecny model pracy: jeden główny serwer i jeden pomocniczy w innym centrum danych. W przypadku awarii przełączenie na zapasowe odbywa się ręcznie za pomocą przez nas napisanego panelu sterowania, który zmienia adresy IP za pośrednictwem API Cloudflare. Serwer pomocniczy działa w trybie replikacji. Clickhouse nie korzysta z replikacji (na etapie tworzenia architektury projektu trzeba było doinstalować Zookeeper, który jest bardzo kapryśny, dlatego prostszym rozwiązaniem wydawał się samodzielny dziennik, który równolegle działa na serwerze zapasowym). Trzeba będzie podjąć decyzję, czy pozostaniemy przy status quo, czy jednak wdrożymy trzy instancje Clickhouse w klastrze z użyciem koordynatora Clickhouse keeper.

- Brak adekwatnego monitoringu stanu serwera (obciążenie procesora, dysku, liczba zawieszonych połączeń, czas przetwarzania żądań). Jednocześnie chcielibyśmy używać otwartych rozwiązań do monitorowania, a nie tych, które mają model subskrypcyjny i działają w oparciu o SaaS, co znacznie zwiększałoby koszty obsługi serwerów.

Zadania

• Konsultacja. Opis obecnego projektu, jego problemów i możliwych ścieżek rozwiązania.
• Tworzymy architekturę serwerową rozwiązania. Zdecydować, jaka będzie struktura pracy MySQL (obecnie jednostronna replikacja) i Clickhouse (tworzymy klaster z dwóch serwerów w centrum danych nr 1 i jednego w centrum danych nr 2 lub pozostawiamy obecny model dwóch niezależnych serwerów z równoczesnym zapisem).
• Tworzymy skrypty Docker-compose. Obraz Docker do konfiguracji PHP-FPM już istnieje, prawdopodobnie część z niego będzie można ponownie wykorzystać. Trzeba podjąć decyzję, czy będziemy mieć jednego Nginx, który będzie obsługiwał trzy projekty (to będzie wymagać oddzielnych folderów konfiguracyjnych, każdy z własnymi domenami dla każdego z projektów) czy też jednego Nginx, który będzie przekierowywał żądania do wewnętrznych kontenerów z Nginx (potencjalnie dowiedzieć się, jakie opóźnienia występują w tym przypadku). Potrzebne obrazy: Nginx, MySQL, Clickhouse, PHP-FPM, Redis. Obecnie do uruchamiania procesów o długim czasie działania używany jest systemctl, prawdopodobnie będzie sens opracować rozwiązanie oparte na supervisord lub innym rozwiązaniu?
• Opracować rozwiązanie, aby dodawanie nowych domen było bardziej zautomatyzowane (w tym generowanie dla nich certyfikatu LetsEncrypt, a następnie automatyczne dodawanie do konfiguracji Nginx).
• Konsultacja dotycząca MySQL. Czy każdy projekt będzie korzystał z własnej instancji MySQL czy będzie korzystał z wspólnej? Mamy stosunkowo niewielką część biznesową w MySQL i kilka dużych tabel logów. Skonsultować, czy warto przenieść tabele logów do osobnej bazy danych lub nawet do osobnej instancji MySQL z własnymi ustawieniami (to może pomóc w szybszym wdrażaniu nowej repliki, ponieważ obecnie do wdrożenia repliki trzeba wykonać pełny backup, który zajmuje dziesiątki gigabajtów i następnie trwa kilka godzin, co może być krytyczne).
• Podejmujemy decyzję odnośnie liczby serwerów, parametrów, ich lokalizacji. Prawdopodobnie będzie trzeba dokupić 1, 2 lub 3 serwery. Część organizacyjną zakupu przejmujemy na siebie, trzeba będzie wybrać najlepszy balans między ceną a mocą serwerów.
• Dostrojenie serwera dla maksymalnej prędkości udzielania odpowiedzi. Konfiguracja parametrów sieciowych jądra pod zadania aplikacji, konfiguracja harmonogramu, trybu pracy procesora/pamięci, ewentualnie - konfiguracja RAID, jeśli zostanie wykonana nieoptymalnie „out of the box”.
• Przygotowanie rozwiązania do automatycznego przełączania na serwer zapasowy (częściowo będzie to zrealizowane wspólnie z zespołem programistów, ale prawdopodobnie będzie konieczna konfiguracja replikacji i konsultacja dotycząca optymalnej ścieżki, jak to wszystko skonfigurować).
• Konfiguracja pliku konfiguracyjnego MySQL dla bardziej optymalnej pracy na odpowiednim sprzęcie.
• Obecnie używany jest skrypt Deployer, który na żądanie pobiera gałąź master i wykonuje wdrożenie z możliwością cofnięcia oraz ponownego uruchomienia wszystkich niezbędnych procesów. Omówić rozwiązanie i sprawdzić, czy istnieje możliwość bardziej optymalnej ścieżki, która będzie odpowiednia dla zespołu programistów.
• Omówić możliwość utworzenia środowiska testowego, na którym będzie można sprawdzić nową funkcjonalność dla menedżerów i testerów.
• Instalacja systemu monitorowania (omówić istniejące rozwiązania, najlepiej bez nadmiernego modelu monetarnego, idealnie self-hosted rozwiązania, a nie SaaS, na przykład Grafana + Prometeus, Zabbix lub inne). System powinien pokazywać ogólną sytuację na wszystkich serwerach - obciążenie, ilość ruchu, średni czas odpowiedzi na określonych endpointach, a także wysyłać powiadomienia w przypadku wystąpienia krytycznych sytuacji.
• Rozwiązanie backupu istnieje, ale prawdopodobnie trzeba będzie je zoptymalizować z uwzględnieniem nowej konfiguracji i stworzyć skrypty do szybszego przywracania danych z kopii zapasowych.
• Wszystkie powyższe kroki (w szczególności szczegóły dostrojenia serwera i procedura wdrażania nowej instancji aplikacji) muszą być starannie udokumentowane, aby wszystkie kroki mógł odtworzyć lider techniczny w przypadku krytycznej potrzeby lub ktoś inny wystarczająco kompetentny w przypadku braku osoby, która skonfigurowała system. Oznacza to, że system nie powinien być „czarną skrzynką”: „ktoś kilka lat temu skonfigurował system i nikt nie wie, dlaczego tak, a nie inaczej, i niejasne jest, jak to zmodyfikować lub przenieść na inny serwer”.