Konserwacja serwera MMORPG

Wygląda na to, że większość gier mmorpg wymaga regularnej konserwacji serwera, niektóre codziennie, niektóre raz w tygodniu. Co tak naprawdę muszą zrobić i dlaczego jest to konieczne?

Jeśli zaczniesz od takiego projektu, co możesz zrobić, aby tego uniknąć?

Podejrzewam, że wdrażają najnowszą wersję swojego kodu, co wymaga ponownego uruchomienia aplikacji (i mam nadzieję, że przeprowadzi kilka testów przed ponownym włączeniem dostępu). Z tego punktu widzenia jest to raczej problem StackOverflow, a mniej ServerFault.

Myślę, że można stworzyć system łatania na gorąco, ale z konieczności byłoby to niezwykle skomplikowane. Z tego, co rozumiem, „aplikacja” serwera MMO składa się z kilku różnych komponentów -

• Serwer logowania - obsługuje uwierzytelnianie i działa jako „centrum” między serwerami gry. Gdy klient jest już w grze, nie wchodzi już w interakcje z serwerem logowania. W takim systemie możesz nakładać łatki i ponownie uruchamiać serwer logowania bez ingerowania w rozgrywkę (chociaż będziesz miał okres, w którym ludzie nie będą mogli się zalogować).

• Serwery rozgrywki - klastry maszyn pogrupowane w logiczne niezależne jednostki („światy” itp.). Zakłada się, że każdy klaster rozgrywki korzysta z pewnego rodzaju wewnętrznego protokołu komunikacyjnego, aby odpowiadać sobie nawzajem; prawdopodobnie będziesz musiał załatać wszystkie klastry naraz. Jednym z możliwych sposobów jest załatanie trybu awaryjnego. Musiałbyś wtedy mieć jedno i drugie

  1. Wskaż klientowi, aby łączył się z ciepłym przełączaniem awaryjnym i rozłączył się ze starym klastrem.
  2. Synchronizuj stan między przełączaniem awaryjnym a nieaktualnym serwerem aplikacji podczas przesyłania wszystkich klientów.

• Serwery baz danych - Trwały magazyn danych, taki jak RDBMS. Mam nadzieję, że tak często nie wprowadzasz zmian w magazynie danych. Przypuszczalnie każdy serwer / klaster rozgrywki ma niezależny magazyn danych. Możesz użyć tej samej sztuczki przy ciepłym przełączaniu awaryjnym (i powiedzieć serwerom gry, aby się rozłączyły, poczekaj na zsynchronizowanie starych i awaryjnych baz danych, a następnie ponownie połącz się z przełączaniem awaryjnym), ale wydaje mi się to dość ryzykowne.

Wszystkie powyższe przypadki powodują niesamowitą złożoność już złożonego systemu i wprowadzają szereg miejsc, w których błąd kodu może spowodować utratę lub uszkodzenie danych.

Innym rozwiązaniem jest użycie języka, który został zaprojektowany pod kątem 100% czasu działania i ma wbudowane możliwości szybkiego uruchamiania kodu. Erlang to dobry wybór ( przykład hotpatchingu ), a Java ma podobną funkcjonalność .

Czy nikt inny nie ma doświadczenia w prowadzeniu czegoś takiego? Huh

Istnieje kilka powodów, które łączą zarówno kod, jak i systemy. Po pierwsze, pamiętaj, że większość obecnych „dużych” silników MMO została zaprogramowana kilka lat temu i pomimo ulepszeń grafiki i technologii od tego czasu wciąż zależą od sposobu, w jaki wiele z tych systemów zostało napisanych w 2000 roku. Na przykład Eve-Online nadal działa na jednej ogromnej instancji Microsoft SQL Server, dlatego zawsze starają się wyciągnąć z niej więcej, aktualizując sprzęt.

Przykładem poprawy od czasu rozpoczęcia WoW i EVE jest praca w rozproszonych bazach danych / kluczach, takich jak MapReduce Google (i jego implementacja typu open source, Hadoop), wyjątkowo szybkie kolejki przetwarzania odpowiedzi twierdzącej (Amazon SQS) i inne „ technologie zorientowane na chmurę.

Mam największe doświadczenie z EVE (jestem bardziej facetem od laserów niż facetem od bitew), więc niektóre z tych przykładów są bardziej zorientowane na EVE.

Jeśli chodzi o powody systemowe:

• Węzły fizyczne ulegają awarii w sposób spójny. Gdy węzeł zawiedzie, zazwyczaj jego aktywność jest migrowana gdzie indziej przy użyciu dowolnej liczby środków. Węzeł należy jednak jak najszybciej przywrócić do użytku. W przypadku EVE używają zarówno języka przetwarzania bez stosów, jak i serwerów wirtualnych; Nie jestem pewien, jak wygląda architektura Blizzarda.
• Spójność bazy danych musi zostać sprawdzona, dzienniki muszą zostać wyczyszczone, a indeksy i pamięci podręczne danych muszą zostać odbudowane. Jest to szczególnie ważne w systemie takim jak EVE z tylko jedną „aktywną” instancją bazy danych.
• Łaty systemu operacyjnego należy nakładać w momencie, gdy mogą one ponownie uruchamiać węzły bez konieczności zbyt dużej aktywności migrującej w innym miejscu. Migracja zajmuje wiele zasobów sieciowych, które w innym przypadku mogłyby zostać przeznaczone na przetwarzanie online.
• MMO oparte na RDBMS mają ogromne problemy z blokowaniem danych i integralnością referencyjną. Przestoje służą do czyszczenia starych blokad i przerw integralności z dzienników aktywności.
• Większość gier implementuje umieszczone geograficznie pamięci podręczne danych dla danych statycznych lub półstatycznych (patrz podsumowanie danych buforowania poniżej) w obszarach intensywnego użytkowania, tj. Na wschodnim wybrzeżu w porównaniu do zachodniego wybrzeża USA. Te pamięci podręczne są aktualizowane ręcznie podczas przestoju.

Jeśli chodzi o powody związane z oprogramowaniem:

• Gry, gdy działają, używają dużo OLTP - to jest Przetwarzanie Transakcji On Line - rodzaj odczytu / zapisu do baz danych. Czasami jednak potrzebujesz raportu podsumowującego ... na przykład, ile konkretnej bestii zabiłeś w ciągu ostatnich 3 lat mielenia. Najlepiej radzi sobie z tym raport OLAP - czyli przetwarzanie analityczne On Line - który zawiera informacje podsumowujące oparte na wielu wierszach w gigantycznym zbiorze danych. W rzeczywistości gry implementują systemy, które wykorzystują OLAP do budowy pamięci podręcznej, aby ograniczyć liczbę zapytań, które należy odczytać - tj. Budują sumę na określony dzień, a kiedy zadajesz pytanie, po prostu czytają wiersze ze sklepu OLTP, które podsumowują okres od określonej daty. Połącz te dwa elementy i możesz oszacować, jak bezwartościowe stało się twoje życie.
• Wspomniane wyżej poprawki, które widzę jako problem z oprogramowaniem, ale twórcy oprogramowania postrzegają jako problem systemowy. ;)
• Uzupełnianie zapasów przedmiotów - w Ewie pasy asteroid są odświeżane każdej nocy, a niektóre kompleksy są również poddawane recyklingowi. Można to zrobić w pewnym stopniu w trybie on-line, ale niektóre algorytmy są zbyt skomplikowane i należy je wykonać w trybie off-line, ponieważ krótko podnoszą bazę danych na kolana, gdy podsumowują aktywność gospodarczą z poprzedniego dnia.

Prowadzenie gospodarki z zamkniętymi i otwartymi pętlami to jeden problem dla operatorów MMO - jeśli mi nie wierzysz, przeczytaj niektóre akademickie artykuły napisane o ekonomii gier i niektóre badania starszych gier, takich jak Ultima Online, które miał względnie prymitywne gospodarki. Analiza, która musi się zdarzyć, aby uzupełnić otwarte pętle i zidentyfikować oszustwo i inną negatywną działalność gospodarczą, musi odbywać się offline z migawką danych, którą czasami można wykonać tylko wtedy, gdy baza danych jest całkowicie zamknięta.

Jeśli zauważysz, konserwacja Eve odbywa się w południe w Anglii, gdzie znajduje się główne centrum danych.

Podejrzewam, że całkowity czas, jaki Blizzard (wnioskuję, biorąc pod uwagę, że zadajesz swoje pytanie we wtorek rano), poświęca na konserwację całego klastra; nie każdy serwer zajmuje tyle czasu, aby wykonać pracę.

Chociaż szybsze tworzenie kopii zapasowych poszczególnych serwerów może być szybsze, byłoby to nielegalnym okrzykiem faworyzowania graczy, których królestwo przypadło wcześniej na harmonogram. Jako takie utrzymują wszystko w dół, dopóki cała praca nie zostanie wykonana; z setkami królestw do pracy, prawdopodobnie wykonują większość pracy równolegle, ale wciąż serializują końcową kontrolę przed przywróceniem rzeczy do trybu online. Jeśli przeprowadzasz aktualizację sprzętu, jest to prawdopodobnie serializowane w wielu centrach danych.

Jeśli chodzi o to, dlaczego przeprowadzają konserwację, niektóre z nich mogą być po prostu restartem wydajności. Byłoby wspaniale, gdyby takie ponowne uruchomienie nie było wymagane, ale koszt takiego działania w porównaniu z konsekwencjami braku takiego działania może kierować ich wyborem tutaj.

Kiedy patrzysz na to, dlaczego nie mogą grupować procesów i wykonywać ciągłej konserwacji, to niewiele osób wie o infrastrukturze WoW sugeruje, że wiele maszyn zapewnia obsługę dla każdej dziedziny (tj. Jeden dla świata, jeden dla instancji i nalotów, jeden dla pól bitewnych itd.) nie używają konfiguracji procesu aktywnej aktywnej współużytkowanej przez stan. Nie ma udostępniania stanu aktywnego, tylko trwałe dane za pośrednictwem bazy danych.

W końcu mechanika dostarczania stanowej usługi online dla tak dużej bazy abonentów podważa niektóre z najlepszych praktyk, które moglibyśmy propagować, mówiąc o stronie internetowej lub innej tradycyjnej usłudze internetowej.

Niektóre z dłuższych przestojów w EvE Online dotyczyły instalowania nowego sprzętu, takiego jak szybsza sieć SAN. Podczas gdy można technicznie przenieść większość danych, tworząc nową grupę plików na nowym dysku, a następnie opróżniając główną, to spowodowałoby to dłuższy okres zmniejszonej wydajności z powodu stałego we / wy. Więc zdecydowali się odłączyć bazę 1.1TB i przenieść go w jednym zamachem.

Odpowiedź na to pytanie zależy również od konkretnego zastosowania. Na przykład serwer obsługujący określony system gwiezdny nie może zostać zamieniony na gorąco bez zakłócania gry, więc przestoje służą do przypisania mocniejszych serwerów do potencjalnych punktów aktywnych. Ponadto obliczane są obliczenia własności (suwerenności) układów gwiezdnych. Zależy to od dziesiątek różnych zmiennych, z których wszystkie mogą się zmieniać w zależności od działań gracza. Nie trzeba dodawać, że wykonanie tego na żywo może powodować nadmierne blokowanie i / lub inne problemy z współbieżnością. Ale zajęcie się tymi problemami najlepiej pozostawić do przepełnienia stosu .

przypuszczalnie coś, z czym nie można sobie poradzić za pomocą klastrowania / równoważenia obciążenia, takie jak duże zmiany schematu DB.

W ostatnim temacie Jak często powinienem restartować serwery linuxowe wspomniałem o innym dobrym punkcie, sprawdzając, czy wszystko uruchamia się poprawnie po restarcie lub po każdej (dużej) zmianie konfiguracji.

Prosta aktualizacja sprzętu (lub wymiana sprzętu) jest również prezentowana jako „konserwacja serwera” przez gry MMORPG. Tak trywialne, że często o tym zapominamy.

W Erlang zaimplementowałem architekturę MMO, która obsługuje aktualizacje i dystrybucję kodu. Na przykład jeden „GamePlay Server” może działać na dowolnej liczbie komputerów, jeśli potrzebna jest aktualizacja sprzętu, jego obiekty mogą być przenoszone (w czasie rzeczywistym) na inne maszyny. Umożliwia to aktualizację oprogramowania bez przestojów.

Możesz sprawdzić moją stronę na http://www.next-gen.cc .

Jestem przekonany, że okno konserwacji pozwala również na rutynową wymianę sprzętu, aby zapewnić, że komponenty nie zawiodą.