Hej Habro! Zwracam uwagę na tłumaczenie artykułu przez Adiba Dawa.
Jeśli ten nagłówek nie wywołuje lekkiego dreszczu na plecach, powinieneś przejść do następnego akapitu lub odwiedzić naszą stronę poświęconą - chcielibyśmy porozmawiać.
Kim jesteśmy
Jesteśmy zespołem 4 pingwinów, którzy uwielbiają pisać kod i pracować ze sprzętem. W wolnym czasie jesteśmy odpowiedzialni za wdrażanie, utrzymanie i obsługę floty ponad 7000 serwerów fizycznych z systemem Linux, rozproszonych w 3 różnych centrach danych w całych Stanach Zjednoczonych.
Mieliśmy również okazję to zrobić 10 000 km od miejsc pracy, w zaciszu własnego biura, które znajduje się kilka minut jazdy od plaży nad Morzem Śródziemnym.
Problemy ze skalą
Chociaż rozpoczęcie działalności od hostingu infrastruktury w chmurze ma sens ze względu na stosunkowo niską inwestycję początkową, my w Outbrain zdecydowaliśmy się na wykorzystanie własnych serwerów. Zrobiliśmy to, ponieważ koszty infrastruktury chmurowej znacznie przewyższają koszty eksploatacji własnego sprzętu zlokalizowanego w centrach danych po rozwinięciu do pewnego poziomu. Ponadto Twój serwer zapewnia najwyższy stopień kontroli i możliwości rozwiązywania problemów.
W miarę rozwoju problemy są zawsze w pobliżu. Co więcej, zwykle występują w grupach. Zarządzanie cyklem życia serwerów wymaga ciągłego samodoskonalenia, aby móc poprawnie funkcjonować w kontekście szybkiego wzrostu liczby serwerów. Metody oprogramowania do zarządzania grupami serwerów w centrach danych szybko stają się nieporęczne. Wykrywanie, rozwiązywanie problemów i łagodzenie awarii przy jednoczesnym spełnieniu standardów QoS staje się kwestią żonglowania niezwykle różnorodnymi zestawami sprzętu, zmiennymi obciążeniami, terminami aktualizacji i innymi przyjemnymi rzeczami, o które nikt nie chce się martwić.
Opanuj swoje domeny
Aby rozwiązać wiele z tych problemów, podzieliliśmy cykl życia serwera w Outbrain na główne komponenty i nazwaliśmy je domenami. Na przykład jedna domena obejmuje wymagania sprzętowe, inna logistykę związaną z cyklem życia zapasów, a trzecia obejmuje komunikację z personelem terenowym. Jest jeszcze jeden dotyczący obserwowalności sprzętu, ale nie będziemy opisywać wszystkich punktów. Naszym celem było zbadanie i zdefiniowanie domen, aby można je było wyodrębnić za pomocą kodu. Po opracowaniu działającej abstrakcji jest ona przekazywana do procesu ręcznego, który jest wdrażany, testowany i udoskonalany. Na koniec domena jest skonfigurowana tak, aby integrowała się z innymi domenami za pośrednictwem interfejsów API, tworząc całościowy, dynamiczny i stale rozwijający się system cyklu życia sprzętu, który można wdrażać, testować i obserwować. Podobnie jak wszystkie nasze inne systemy produkcyjne.
Przyjęcie takiego podejścia pozwoliło nam poprawnie rozwiązać wiele problemów – poprzez stworzenie narzędzi i automatyzację.
Potrzebujesz domeny
Chociaż na początku poczta elektroniczna i arkusze kalkulacyjne były realnym sposobem zaspokojenia popytu, nie okazało się to skutecznym rozwiązaniem, zwłaszcza gdy liczba serwerów i liczba przychodzących żądań osiągnęła pewien poziom. Aby lepiej organizować i ustalać priorytety przychodzących żądań w obliczu szybkiego rozwoju, musieliśmy zastosować system sprzedaży biletów, który mógł oferować:
- Możliwość dostosowania widoku tylko odpowiednich pól (proste)
- Otwarte API (rozszerzalne)
- Znany naszemu zespołowi (zrozumiany)
- Integracja z naszymi istniejącymi przepływami pracy (ujednolicona)
Ponieważ do zarządzania sprintami i zadaniami wewnętrznymi używamy Jira, postanowiliśmy stworzyć kolejny projekt, który ułatwiłby naszym klientom przesyłanie zgłoszeń i śledzenie ich wyników. Wykorzystanie Jira do obsługi przychodzących żądań i zarządzania zadaniami wewnętrznymi pozwoliło nam stworzyć jedną tablicę Kanban, która pozwoliła nam spojrzeć na wszystkie procesy jako całość. Nasi wewnętrzni „klienci” widzieli jedynie zapytania o sprzęt, bez wchodzenia w mniej istotne szczegóły dodatkowych zadań (takich jak ulepszanie narzędzi, naprawianie błędów).
Tablica Kanban w Jira
Jako bonus, fakt, że kolejki i priorytety były teraz widoczne dla wszystkich, pozwolił zrozumieć, „gdzie w kolejce” znajdowało się dane żądanie i co je poprzedzało. Umożliwiło to właścicielom zmianę priorytetów własnych żądań bez konieczności kontaktowania się z nami. Przeciągnij i to wszystko. Pozwoliło nam to również monitorować i oceniać nasze SLA według typów żądań w oparciu o metryki generowane w Jira.
Domena cyklu życia sprzętu
Spróbuj wyobrazić sobie złożoność zarządzania sprzętem używanym w każdej szafie serwerowej. Co gorsza, wiele elementów sprzętu (RAM, ROM) można przenieść z magazynu do serwerowni i z powrotem. One również ulegają awarii lub są spisywane na straty, wymieniane i zwracane dostawcy w celu wymiany/naprawy. O tym wszystkim należy poinformować pracowników serwisu kolokacyjnego zajmujących się fizyczną konserwacją sprzętu. Aby rozwiązać te problemy, stworzyliśmy wewnętrzne narzędzie o nazwie Floppy. Jego zadaniem jest:
- Zarządzanie komunikacją z personelem terenowym, agregacja wszystkich informacji;
- Aktualizacja danych „magazynowych” po każdym wykonanym i zweryfikowanym zadaniu konserwacji sprzętu.
Magazyn z kolei wizualizujemy za pomocą Grafany, na której wykreślamy wszystkie nasze metryki. Dlatego tego samego narzędzia używamy do wizualizacji magazynu i do innych potrzeb produkcyjnych.
Panel sterowania urządzeniami magazynowymi w Grafanie
W przypadku urządzeń serwerowych objętych gwarancją używamy innego narzędzia, które nazywamy Dispatcher. On:
- Zbiera logi systemowe;
- Generuje raporty w formacie wymaganym przez dostawcę;
- Tworzy żądanie od dostawcy poprzez API;
- Odbiera i przechowuje identyfikator aplikacji w celu dalszego śledzenia jej postępu.
Po uznaniu naszej reklamacji (zwykle w godzinach pracy) część zamienna jest wysyłana do odpowiedniego centrum danych i akceptowana przez personel.
Dane wyjściowe konsoli Jenkins
Domena komunikacyjna
Aby nadążyć za szybkim rozwojem naszego biznesu, który wymaga coraz większej wydajności, musieliśmy dostosować sposób, w jaki współpracujemy ze specjalistami technicznymi w lokalnych centrach danych. Jeśli na początku skalowanie oznaczało zakup nowych serwerów, to po projekcie konsolidacyjnym (opartym na przejściu na Kubernetes) stało się to czymś zupełnie innym. Nasza ewolucja od „dodawania szaf” do „zmiany przeznaczenia serwerów”.
Zastosowanie nowego podejścia wymagało także nowych narzędzi, które umożliwiły wygodniejszą interakcję z personelem centrum danych. Narzędzia te były potrzebne do:
- Prostota;
- autonomia;
- Efektywność;
- Niezawodność.
Musieliśmy wyłączyć się z łańcucha i tak zorganizować pracę, aby technicy mogli bezpośrednio pracować ze sprzętem serwerowym. Bez naszej interwencji i bez regularnego poruszania wszystkich tych kwestii dotyczących obciążenia pracą, godzin pracy, dostępności sprzętu itp.
Aby to osiągnąć, w każdym centrum danych zainstalowaliśmy iPady. Po połączeniu się z serwerem wydarzy się co następuje:
- Urządzenie potwierdza, że ten serwer faktycznie wymaga trochę pracy;
- Aplikacje działające na serwerze są zamykane (jeśli to konieczne);
- Zestaw instrukcji pracy jest publikowany na kanale Slack wyjaśniając wymagane kroki;
- Po zakończeniu pracy urządzenie sprawdza poprawność stanu końcowego serwera;
- W razie potrzeby ponownie uruchamia aplikacje.
Dodatkowo przygotowaliśmy również bota Slack, który pomoże technikowi. Dzięki szerokiemu zakresowi możliwości (ciągle rozwijaliśmy funkcjonalność) bot ułatwił im pracę, a także znacznie ułatwił nam życie. W ten sposób zoptymalizowaliśmy większość procesu zmiany przeznaczenia i konserwacji serwerów, eliminując się z przepływu pracy.
iPad w jednym z naszych centrów danych
Domena sprzętowa
Niezawodne skalowanie naszej infrastruktury centrum danych wymaga dobrego wglądu w każdy komponent, na przykład:
- Wykrywanie awarii sprzętu
- Stany serwera (aktywny, hostowany, zombie itp.)
- Zużycie energii
- Wersja oprogramowania
- Analityka dla całego biznesu
Nasze rozwiązania pozwalają nam podejmować decyzje o tym, jak, gdzie i kiedy zakupić sprzęt, czasem nawet zanim będzie on faktycznie potrzebny. Ponadto, określając poziom obciążenia różnych urządzeń, byliśmy w stanie osiągnąć lepszą alokację zasobów. W szczególności zużycie energii. Możemy teraz podejmować świadome decyzje dotyczące rozmieszczenia serwera, zanim zostanie on zainstalowany w szafie i podłączony do źródła zasilania, przez cały cykl jego życia, aż do ostatecznego wycofania go z użytku.
Panel energetyczny w Grafanie
A potem pojawił się Covid-19…
Nasz zespół tworzy technologie, które umożliwiają firmom medialnym i wydawcom online pomaganie odwiedzającym w znajdowaniu odpowiednich treści, produktów i usług, które mogą ich zainteresować. Nasza infrastruktura została zaprojektowana tak, aby obsługiwać ruch generowany w momencie publikacji ekscytujących wiadomości.
Intensywne relacje w mediach na temat Covid-19 w połączeniu ze wzrostem ruchu oznaczały, że pilnie musieliśmy nauczyć się radzić sobie z tą presją. Co więcej, wszystko to trzeba było zrobić w czasie światowego kryzysu, kiedy łańcuchy dostaw zostały zakłócone, a większość personelu była w domu.
Ale, jak powiedzieliśmy, nasz model już zakłada, że:
- Sprzęt w naszych centrach danych jest w większości fizycznie niedostępny dla nas;
- Prawie całą pracę fizyczną wykonujemy zdalnie;
- Praca odbywa się asynchronicznie, autonomicznie i na dużą skalę;
- Zapotrzebowanie na sprzęt zaspokajamy metodą „budowania z części” zamiast zakupu nowego sprzętu;
- Posiadamy magazyn, który pozwala nam stworzyć coś nowego, a nie tylko przeprowadzać rutynowe naprawy.
Tym samym globalne ograniczenia, które uniemożliwiały wielu firmom uzyskanie fizycznego dostępu do swoich data center, miały na nas niewielki wpływ, a jeśli chodzi o części zamienne i serwery, tak, staraliśmy się zapewnić stabilną pracę sprzętu. Zrobiono to jednak, aby zapobiec możliwym zdarzeniom, gdy nagle okaże się, że jakiś element sprzętu jest niedostępny. Dbaliśmy o to, aby nasze rezerwy były uzupełnione, nie mając na celu zaspokojenia bieżącego zapotrzebowania.
Podsumowując, chciałbym powiedzieć, że nasze podejście do pracy w branży data center udowadnia, że możliwe jest zastosowanie zasad dobrego projektowania kodu do fizycznego zarządzania centrum danych. Być może uznasz to za interesujące.
Original:
Źródło: www.habr.com