Cześć wszystkim. Pracuję jako główny administrator systemów w OK i odpowiadam za stabilne działanie portalu. Chcę opowiedzieć, jak zorganizowaliśmy proces automatycznej wymiany dysków, a następnie, jak wyeliminowaliśmy administratora z tego procesu, zastępując go botem.
Ten artykuł jest swoistą transliteracją na HighLoad+ 2018
Budowanie procesu wymiany dysków
Najpierw kilka cyfr
OK to gigantyczny serwis, z którego korzystają miliony ludzi. Obsługuje go około 7 tys. serwerów rozmieszczonych w 4 różnych centrach danych. Na serwerach znajduje się ponad 70 tys. dysków. Gdyby je ułożyć jeden na drugim, powstała by wieża o wysokości ponad 1 km.
Dyski twarde to komponent serwera, który psuje się najczęściej. Przy takich ilościach musimy wymieniać około 30 dysków tygodniowo, a ta procedura stała się dość nieprzyjemną rutyną.
Incydenty
W naszej firmie wprowadzono pełnoprawny zarząd niemal wszystkimi incydentami. Każdy incydent rejestrujemy w Jira, a następnie rozwiązujemy i omawiamy. Jeśli incydent miał wpływ na użytkowników, koniecznie się spotykamy i zastanawiamy, jak szybciej reagować w takich sytuacjach, jak zminimalizować wpływ i oczywiście jak zapobiegać powtórkom.
Nośniki nie są wyjątkiem. Ich stan monitoruje Zabbix. Śledzimy wiadomości w Syslog pod kątem błędów zapisu/odczytu, analizujemy stan HW/SW macierzy, monitorujemy SMART, a dla SSD obliczamy zużycie.
Jak przebiegała wymiana dysków wcześniej
Kiedy w Zabbix zapala się jakiś wyzwalacz, w Jira tworzy się incydent, który automatycznie przypisuje się do odpowiednich inżynierów w centrach danych. Tak robimy ze wszystkimi incydentami sprzętowymi, czyli takimi, które wymagają jakiejkolwiek pracy fizycznej z urządzeniami w centrum danych.
Inżynier centrum danych to osoba, która zajmuje się kwestiami związanymi ze sprzętem, odpowiada za instalację, konserwację, demontaż serwerów. Otrzymując zgłoszenie, inżynier przystępuje do pracy. W szafach dyskowych wymienia dyski samodzielnie. Jednak jeśli nie ma dostępu do potrzebnego urządzenia, inżynier zwraca się o pomoc do dyżurnych administratorów systemów. W pierwszej kolejności trzeba wyłączyć dysk z rotacji. W tym celu należy wprowadzić odpowiednie zmiany na serwerze, zatrzymać aplikacje, odmontować dysk.
Dyżurny administrator systemów odpowiada za działanie całego portalu w czasie swojej zmiany roboczej. Rozwiązuje incydenty, zajmuje się naprawami, wspiera programistów w wykonywaniu drobnych zadań. Nie zajmuje się jedynie dyskami twardymi.
Dawniej inżynierowie centrów danych komunikowali się z administratorem systemów na czacie. Inżynierowie wysyłali linki do ticketów Jira, a administrator przechodził przez nie, prowadząc dziennik prac w jakimś notatniku. Jednak czaty nie są wygodne na takie zadania: informacje są tam nieustrukturyzowane i szybko giną. Administrator mógł też po prostu odejść od komputera i przez pewien czas nie odpowiadać na zapytania, podczas gdy inżynier stał przy serwerze z paczką dysków i czekał.
Najgorsze było to, że administratorzy nie widzieli pełnego obrazu: jakie występują incydenty dyskowe, gdzie potencjalnie może pojawić się problem. To związane jest z tym, że wszystkie incydenty HW przekazujemy inżynierom. Tak, można było przedstawić wszystkie incydenty na pulpicie administratora. Ale było ich bardzo dużo, a administrator zajmował się tylko niektórymi z nich.
Ponadto, inżynier nie mógł prawidłowo ustalić priorytetów, ponieważ nic nie wiedział o przeznaczeniu konkretnych serwerów ani o rozkładzie informacji na nośnikach.
Nowa procedura wymiany
Pierwszą rzeczą, jaką zrobiliśmy, to wyodrębniliśmy wszystkie incydenty dyskowe do osobnego typu „HW-dysk” i dodaliśmy do niego pola „nazwa urządzenia blokowego”, „rozmiar” i „typ dysku”, aby te informacje były zapisywane w tickecie, a nie trzeba było ich ciągle wymieniać w czacie.
Ponadto ustaliliśmy, że w ramach jednego incydentu będziemy wymieniać tylko jeden dysk. To znacznie uprościło późniejszy proces automatyzacji, zbierania statystyk i pracy.
Dodatkowo dodaliśmy pole „odpowiedzialny administrator”. Tam automatycznie przypisuje się dyżurnego admina. To bardzo wygodne, ponieważ teraz inżynier zawsze widzi, kto jest odpowiedzialny. Nie trzeba przeszukiwać kalendarza. To właśnie to pole pozwoliło wyświetlić na pulpicie administratora tickety, w których być może będzie potrzebna jego pomoc.
Aby wszyscy uczestnicy mogli maksymalnie skorzystać z innowacji, stworzyliśmy filtry i pulpity nawigacyjne, a następnie omówiliśmy je z zespołem. Kiedy ludzie rozumieją zmiany, nie dystansują się od nich jak od czegoś niepotrzebnego. Inżynier musi wiedzieć, który numer szafy mieści serwer oraz rozmiar i typ dysku. Administrator, przede wszystkim, powinien rozumieć, czym jest grupa serwerów oraz jaki może być efekt wymiany dysku.
Obecność pól i ich wyświetlanie to wygodne rozwiązanie, ale nie uwolniło nas od konieczności korzystania z czatów. W tym celu musieliśmy zmienić proces pracy.
Dawniej wyglądało to tak:
Dziś w taki sposób wciąż pracują inżynierowie, gdy nie potrzebują pomocy administratora.
Pierwszą rzeczą, którą zrobiliśmy, było wprowadzenie nowego statusu Investigate. W tym statusie zgłoszenie znajduje się, kiedy inżynier jeszcze nie zdecydował, czy potrzebuje administratora, czy nie. Poprzez ten status inżynier może przekazać zgłoszenie administratorowi. Oprócz tego tym statusem oznaczamy zgłoszenia, kiedy wymagana jest wymiana dysku, ale sam dysk nie jest dostępny na platformie. Takie sytuacje zdarzają się w przypadku CDN i zdalnych lokalizacji.
Dodatkowo dodaliśmy status Gotowy. Do tego statusu zgłoszenie jest przenoszone po wymianie dysku. Oznacza to, że wszystko zostało już zrobione, ale serwer synchronizuje HW/SW RAID. Może to zająć dość dużo czasu.
Jeśli do pracy angażowany jest administrator, schemat nieco się komplikuje.
Z statusu Otwórz zgłoszenie może przenieść zarówno administrator systemu, jak i inżynier. W statusie In progress administrator wyjmuje dysk z rotacji, aby inżynier mógł go po prostu wyjąć: włącza podświetlenie, odmontowuje dysk, zatrzymuje aplikacje w zależności od konkretnej grupy serwerów.
Następnie zgłoszenie przenoszone jest do Ready to change: to sygnał dla inżyniera, że dysk można wyjąć. Wszystkie pola w Jira są już wypełnione, inżynier wie, jaki typ i rozmiar dysku. Te dane są wprowadzane automatycznie w poprzednim statusie lub przez administratora.
Po wymianie dysku zgłoszenie jest przenoszone do statusu Changed. Sprawdzane jest, czy włożono właściwy dysk, wykonuje się partycjonowanie, uruchamia aplikację oraz wykonuje określone zadania związane z przywracaniem danych. Zgłoszenie może także być przeniesione do statusu Gotowy, w tym przypadku odpowiedzialność pozostaje po stronie administratora, ponieważ to on wprowadzał dysk do rotacji. Pełny schemat wygląda tak.
Dodanie nowych pól znacznie ułatwiło nam życie. Chłopaki zaczęli pracować ze zorganizowanymi informacjami, a teraz wyraźnie widać, co i na jakim etapie należy zrobić. Priorytety stały się znacznie bardziej relewantne, ponieważ teraz ustawia je administrator.
Zniknęła potrzeba rozmów na czacie. Oczywiście administrator może napisać inżynierowi "tu trzeba szybciej wymienić" lub "już wieczór, zdążysz wymienić?". Ale już nie rozmawiamy codziennie na czat dotyczący tych kwestii.
Dyski zaczęto wymieniać hurtowo. Jeśli administrator przychodzi do pracy trochę wcześniej, ma trochę wolnego czasu, a jeszcze nic się nie stało, może przygotować szereg serwerów do wymiany: ustawić pola, wyłączyć dyski z rotacji i przekazać zadanie inżynierowi. Inżynier przychodzi później do centrum danych, widzi zadanie, zabiera z magazynu potrzebne dyski i od razu wymienia. W rezultacie zwiększyła się szybkość wymiany.
Doświadczenie wyniesione przy budowie Workflow
- Przy tworzeniu procedury należy zbierać informacje z różnych źródeł.
Niektórzy nasi administratorzy nie wiedzieli, że inżynier samodzielnie wymienia dyski. Niektórzy uważali, że inżynierowie monitorują synchronizację MD RAID, chociaż niektórzy z nich nie mieli nawet do tego dostępu. Niektórzy główni inżynierowie to robili, ale nie zawsze, ponieważ proces nie był nigdzie opisany. - Procedura powinna być prosta i zrozumiała.
Człowiekowi trudno jest utrzymać w głowie wiele kroków. Najważniejsze sąsiednie statusy w Jira należy przenieść na główny ekran. Można je nazywać inaczej, na przykład, w toku nazywamy Gotowe do zmiany. A inne statusy można ukryć w wyskakującym menu, aby nie przeszkadzały w pracy. Ale lepiej nie ograniczać ludzi, dać im możliwość dokonywania przejść.
Wyjaśniaj wartość innowacji. Kiedy ludzie rozumieją, lepiej przyjmują nową procedurę. Dla nas było bardzo ważne, aby ludzie nie klikali przez cały proces, a szli zgodnie z nim. Następnie oparliśmy na tym automatyzację. - Czekać, analizować, rozwiązywać.
Zajęło nam około miesiąca zbudowanie procedury, realizację techniczną, spotkania i dyskusje. A wdrożenie zajęło ponad trzy miesiące. Widziałem, jak ludzie powoli zaczynają korzystać z innowacji. Na początku było dużo negatywnych opinii. Ale nie miało to absolutnie nic wspólnego z samą procedurą czy jej realizacją techniczną. Na przykład, jeden z administratorów korzystał z wtyczki Jira w Confluence, a nie z samej Jira, przez co niektóre rzeczy były dla niego niedostępne. Po pokazaniu mu Jira, jego produktywność wzrosła zarówno w sprawach ogólnych, jak i przy wymianie dysków.
Automatyzacja wymiany dysków
Do automatyzacji wymiany dysków podchodziliśmy kilka razy. Mieliśmy już opracowania, skrypty, ale wszystkie działały w trybie interaktywnym lub ręcznym, co wymagało uruchomienia. Dopiero po wdrożeniu nowej procedury zrozumieliśmy, że właśnie tego nam brakowało.
Teraz, gdy proces wymiany jest podzielony na etapy, z określonym wykonawcą i listą działań dla każdego z nich, możemy stopniowo włączać automatyzację, a nie od razu w całości. Na przykład, najprostszy etap — Ready (sprawdzenie synchronizacji RAID/danych) można łatwo delegować botowi. Kiedy bot trochę się nauczy, można mu dać bardziej odpowiedzialne zadanie — wprowadzenie dysku do rotacji itd.
ZOO konfiguracji
Zanim opowiem o bocie, zróbmy mały wstęp do naszego zoo instalacji. Przede wszystkim jest to spowodowane ogromnym rozmiarem naszej infrastruktury. Po drugie, dla każdego serwisu staramy się dobrać optymalną konfigurację sprzętu. Mamy około 20 modeli sprzętowego RAID, głównie LSI i Adaptec, ale pojawiają się także HP i DELL w różnych wersjach. Każdy kontroler RAID ma swoją własną aplikację zarządzającą. Zestaw poleceń i wydania mogą się różnić w zależności od wersji każdego kontrolera RAID. Tam, gdzie nie używa się HW-RAID, może być mdraid.
Praktycznie wszystkie nowe instalacje wykonujemy bez rezerwacji dyskowej. Staramy się coraz więcej nie używać sprzętowego i programowego RAID, ponieważ rezerwujemy nasze systemy na poziomie centrów danych, a nie serwerów. Oczywiście, są też liczne serwery starych generacji, które musimy utrzymywać.
Gdzieś dyski w kontrolerach RAID są podłączane jako raw, a gdzie indziej używane są JBOD. Są konfiguracje z jednym dyskiem systemowym w serwerze, i gdy trzeba go wymienić, należy ponownie zainstalować system operacyjny i aplikacje, a także te same wersje, następnie dodać pliki konfiguracyjne i uruchomić aplikacje. Istnieje również wiele grup serwerów, gdzie zabezpieczenie odbywa się nie na poziomie systemu dyskowego, lecz bezpośrednio w samych aplikacjach.
Łącznie mamy ponad 400 unikalnych grup serwerów, na których działa około 100 różnych aplikacji. Aby pokryć tak ogromną liczbę wariantów, potrzebowaliśmy wielofunkcyjnego narzędzia automatyzacji. Najlepiej z prostym DSL, aby mógł to wspierać nie tylko ten, kto to napisał.
Wybraliśmy Ansible, ponieważ jest bezagentowy: nie trzeba było przygotowywać infrastruktury, szybki start. Ponadto jest napisany w Pythonie, który został przyjęty jako standard w zespole.
Ogólny schemat
Przyjrzyjmy się ogólnemu schematowi automatyzacji na przykładzie jednego incydentu. Zabbix wykrywa, że dysk sdb uległ awarii, uruchamia się wyzwalacz, tworzony jest ticket w Jira. Administrator przegląda go, zdaje sobie sprawę, że nie jest to duplikat ani false positive, to znaczy trzeba wymienić dysk, i przenosi tiket do statusu In progress.
Aplikacja DiskoBot, napisana w Pythonie, okresowo sprawdza Jira pod kątem nowych ticketów. Zauważa, że pojawił się nowy ticket w statusie In progress, wyzwalany jest odpowiedni wątek, który uruchamia playbook w Ansible (jest to robione dla każdego statusu w Jira). W tym przypadku uruchamiane jest Prepare2change.
Ansible łączy się z hostem, wypina dysk z rotacji i zgłasza status aplikacji przez Callbacks.
Na podstawie wyników bot automatycznie przenosi ticket do Ready to change. Inżynier otrzymuje powiadomienie i idzie wymienić dysk, po czym przenosi ticket do Changed.
Na podstawie opisanego schematu ticket wraca do bota, który uruchamia inny playbook, idzie na hosta i wprowadza dysk do rotacji. Bot zamyka ticket. Hurra!
Teraz porozmawiajmy o niektórych komponentach systemu.
Diskobot
Ta aplikacja jest napisana w Pythonie. Wybiera tickety z Jira zgodnie z JQL. W zależności od statusu ticketu, trafia on do odpowiedniego handlera, który następnie uruchamia odpowiedni playbook Ansible zgodny ze statusem.
JQL i interwały zapytań są zdefiniowane w pliku konfiguracyjnym aplikacji.
jira_states:
investigate:
jql: '… status = Open i "Disk Size" jest PUSTY'
interval: 180
inprogress:
jql: '… i "Disk Size" nie jest PUSTY i "Device Name" nie jest PUSTY'
ready:
jql: '… i (labels nie w ("dbot_ignore") lub labels jest PUSTY)'
interval: 7200
Na przykład, wśród zgłoszeń w statusie In progress wybierane są tylko te, które mają wypełnione pola Disk size i Device name. Device name to nazwa urządzenia blokowego, które jest potrzebne do wykonania playbooka. Disk size jest potrzebny, aby inżynier wiedział, jakiej wielkości dysku potrzebuje.
W przypadku zgłoszeń ze statusem Ready filtrujemy zgłoszenia z etykietą dbot_ignore. Swoją drogą, etykiety w Jira używamy zarówno do takiej filtracji, jak i do oznaczania zduplikowanych zgłoszeń oraz zbierania statystyk.
W przypadku awarii playbooka Jira przypisuje etykietę dbot_failed, aby później można było rozwiązać problem.
Interakcja z Ansible
Aplikacja współdziała z Ansible poprzez . W playbook_executor przekazujemy nazwę pliku oraz zestaw zmiennych. Pozwala to na przechowywanie projektu Ansible w postaci standardowych plików yml, a nie kodu Python.
Także w Ansible przez *extra_vars* przekazujemy nazwę urządzenia blokowego, status zgłoszenia oraz callback_url, w którym ukryty jest klucz zgłoszenia — jest on używany do callbacków w HTTP.
Dla każdego uruchomienia generowany jest tymczasowy inventarz, składający się z jednego hosta oraz grupy, do której należy ten host, aby zastosować group_vars.
Oto przykład zadania, w którym zrealizowano HTTP callback.
Wyniki wykonania playbooków uzyskujemy za pomocą callbacków. Są one dwóch typów:
- , dostarcza danych dotyczących wyników wykonywania playbooka. Opisuje zadania, które zostały uruchomione, zakończone powodzeniem lub niepowodzeniem. Ten callback jest wywoływany po zakończeniu wykonywania playbooka.
- HTTP callback do pozyskiwania informacji w trakcie wykonywania playbooka. W zadaniu Ansible wykonujemy zapytanie POST/GET w stronę naszej aplikacji.
Przez HTTP callbacki przekazywane są zmienne, które zostały określone podczas wykonywania playbooka i które chcemy przechować oraz wykorzystać w późniejszych uruchomieniach. Dane te zapisujemy w sqlite.
Także przez HTTP callback zostawiamy komentarze i zmieniamy status zgłoszenia.
HTTP callback
# Make callback to Diskobot App
# Variables:
# callback_post_body: # A dict with follow keys. All keys are optional
# msg: If exist it would be posted to Jira as comment
# data: If exist it would be saved in Incident.variables
# desire_state: Set desire_state for incident
# status: If exist Proceed issue to that status
- name: Callback to Diskobot app (jira comment/status)
uri:
url: "{{ callback_url }}/{{ devname }}"
user: "{{ diskobot_user }}"
password: "{{ diskobot_pass }}"
force_basic_auth: True
method: POST
body: "{{ callback_post_body | to_json }}"
body_format: json
delegate_to: 127.0.0.1
Podobnie jak wiele innych zadań, przenieśliśmy je do osobnego pliku wspólnego i włączamy w razie potrzeby, aby nie powtarzać ich ciągle w playbookach. Występuje tutaj callback_url, w którym zakodowane są klucz zgłoszenia i nazwa hosta. Kiedy Ansible wykonuje ten POST-request, bot rozumie, że dotarł w ramach takiego incydentu.
Oto przykład z playbooka, w którym wyłączaliśmy dysk z urządzenia MD:
# Save mdadm configuration
- include: common/callback.yml
vars:
callback_post_body:
status: 'Ready to change'
msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}"
data:
mdadm_data: "{{ mdadm_remove_disk.removed }}"
parted_info: "{{ parted_info | default() }}"
when:
- mdadm_remove_disk | changed
- mdadm_remove_disk.removed
To zadanie zmienia status zgłoszenia Jira na „Gotowy do zmiany” i dodaje komentarz. W zmiennej mdam_data zapisywana jest lista urządzeń md, z których usunięto dysk, a w parted_info - zrzut partycji z parted.
Kiedy inżynier włoży nowy dysk, będziemy mogli wykorzystać te zmienne, aby przywrócić zrzut partycji i dodać dysk do tych urządzeń md, z których został usunięty.
Tryb sprawdzania Ansible
Włączenie automatyzacji było przerażające. Dlatego zdecydowaliśmy się uruchamiać wszystkie playbooki w trybie
, w którym Ansible nie wykonuje żadnych działań na serwerach, a jedynie je emuluje.
Takie uruchomienie jest realizowane przez osobny moduł callback, a wynik wykonania playbooka zostaje zapisany w Jira w postaci komentarza.
Po pierwsze, umożliwiło to walidację działania bota i playbooków. Po drugie, zwiększyło zaufanie administratorów do bota.
Kiedy przeszliśmy walidację i zrozumieliśmy, że można uruchamiać Ansible nie tylko w trybie dry run, dodaliśmy w Jira przycisk Uruchom Diskobot do uruchamiania tego samego playbooka z tymi samymi zmiennymi na tym samym hoście, ale w normalnym trybie.
Ponadto przycisk służy do ponownego uruchamiania playbooka w przypadku jego awarii.
Struktura Playbooks
Już wspomniałem, że w zależności od statusu zgłoszenia Jira, bot uruchamia różne playbooki.
Po pierwsze, ułatwia to organizację wejścia.
Po drugie, w niektórych przypadkach jest to po prostu konieczne.
Na przykład, podczas wymiany dysku systemowego najpierw należy udać się do systemu wdrażania, stworzyć zadanie, a po poprawnym wdrożeniu serwer stanie się dostępny przez ssh, i można na niego nałożyć aplikację. Gdybyśmy wszystko to robili w jednym playbooku, Ansible nie byłby w stanie go wykonać z powodu niedostępności hosta.
Używamy ról Ansible dla każdej grupy serwerów. Tutaj widać, jak zorganizowane są playbooki w jednej z nich.
To jest wygodne, ponieważ od razu wiadomo, gdzie znajdują się poszczególne zadania. W pliku main.yml, który jest głównym punktem wejścia dla roli Ansible, możemy mieć po prostu includa według statusu zgłoszenia lub ogólne zadania, które są potrzebne dla wszystkich, na przykład przejście identyfikacji lub uzyskanie tokena.
Investigation.yml
Uruchamiany dla zgłoszeń w statusie Investigation i Open. Najważniejszą informacją dla tego playbooka jest nazwa urządzenia blokowego. Informacja ta nie zawsze jest dostępna.
Aby ją uzyskać, analizujemy podsumowanie w Jira, ostatnią wartość z wyzwalacza Zabbixa. Może tam być zawarta nazwa urządzenia blokowego — jeśli mamy szczęście. Może też być zawarty punkt montażu — wtedy musimy wejść na serwer, przeanalizować i obliczyć odpowiedni dysk. Wyzwalacz może również przekazać adres scsi lub inne informacje. Może zdarzyć się także, że nie ma żadnych wskazówek i musimy szczegółowo analizować.
Wyjaśniając nazwę urządzenia blokowego, zbieramy informacje o typie i rozmiarze dysku, aby wypełnić pola w Jira. Zbieramy również dane o producencie, modelu, wersji oprogramowania, ID, SMART, a następnie wszystko to wstawiamy do komentarza w zgłoszeniu Jira. Teraz administrator i inżynier nie muszą szukać tych informacji. 🙂
prepare2change.yml
Wydanie dysku z rotacji, przygotowanie do wymiany. To najtrudniejszy i najodpowiedzialniejszy etap. Właśnie tutaj można zatrzymać aplikację, kiedy nie można jej zatrzymywać. Lub wyjąć dysk, z którego brakowało replik, co może wpłynąć na użytkowników, stracić jakieś dane. Tutaj mamy najwięcej kontroli i powiadomień w czacie.
W najprostszym przypadku chodzi o usunięcie dysku z HW/MD RAID.
W bardziej skomplikowanych sytuacjach (w naszych systemach pamięci), gdy replikacja jest realizowana na poziomie aplikacji, konieczne jest skorzystanie z API aplikacji, zgłoszenie wydania dysku, dezaktywacja go i uruchomienie procesu odzyskiwania.
Obecnie masowo migrujemy do , a jeśli serwer jest w chmurze, to Diskobot zwraca się do API chmury, informuje, że zamierza pracować z tym minionkiem — serwerem, na którym uruchomione są kontenery — i prosi: „zmigruj wszystkie kontenery z tego minionka”. I przy okazji włącza podświetlenie dysku, aby inżynier od razu zobaczył, który trzeba wyjąć.
changed.yml
Po wymianie dysku najpierw sprawdzamy jego dostępność.
Inżynierowie nie zawsze montują nowe dyski, dlatego dodaliśmy kontrolę spełniania przez nie wymaganych wartości SMART.
Jakie atrybuty analizujemyLiczba przerzuconych sektorów (5) < 100
Bieżąca liczba oczekujących sektorów (107) == 0
Jeśli dysk nie przechodzi testu, inżynier zostaje poinformowany o konieczności wymiany. Jeśli wszystko jest w porządku, podświetlenie gaśnie, nanosi się oznaczenie i dysk zostaje wprowadzony do rotacji.
ready.yml
Najprostszy przypadek: sprawdzanie synchronizacji RAID HW/SW lub zakończenie synchronizacji danych w aplikacji.
API aplikacji
Wielokrotnie wspominałem, że bot często korzysta z API aplikacji. Oczywiście nie wszystkie aplikacje miały wymagane metody, więc trzeba było je wdrożyć. Oto najważniejsze metody, z których korzystamy:
- Status. Status klastra lub dysku, aby zrozumieć, czy można z nim pracować;
- Start/stop. Aktywacja-dezaktywacja dysku;
- Migrate/restore. Migracja i przywracanie danych w trakcie i po wymianie.
Zebrane doświadczenie dotyczące Ansible
Bardzo lubię Ansible. Jednak często, gdy patrzę na różne projekty open source i widzę, jak ludzie piszą playbooki, czuję się nieco przestraszony. Złożone logiczne sploty z when/loop, brak elastyczności i idempotencji z powodu częstego używania shell/command.
Postanowiliśmy maksymalnie uprościć wszystko, korzystając z zalety Ansible — modułowości. Na najwyższym poziomie znajdują się playbooki, które może pisać każdy administrator, zewnętrzny programista, który trochę zna Ansible.
- name: Migać dyskiem
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Jeśli jakąkolwiek logikę trudno zrealizować w playbookach, przenosimy ją do modułu Ansible lub filtru. Skrypty mogą być napisane w Pythonie lub w innym języku.
Są łatwe i szybkie do napisania. Na przykład moduł podświetlania dysku, którego przykład użycia przedstawiono powyżej, składa się z 265 linii.
Na najniższym poziomie znajduje się biblioteka. Dla tego projektu napisaliśmy oddzielną aplikację, pewnego rodzaju abstrakcję nad sprzętowymi i programowymi RAID, które wykonują odpowiednie zapytania.
Najsilniejszymi stronami Ansible są prostota i zrozumiałe playbooki. Uważam, że należy z tego korzystać i nie generować przerażających plików yaml oraz ogromnej ilości warunków, kodu shell i pętli.
Jeśli chcesz powtórzyć nasze doświadczenie z Ansible API, weź pod uwagę dwie rzeczy:
- Playbook_executor i w ogóle playbook nie pozwalają na przekazanie timeoutu. Jest timeout na sesji ssh, ale nie ma timeoutu na playbooku. Jeśli próbujemy odmontować dysk, który w systemie już nie istnieje, playbook będzie działał w nieskończoność, dlatego musieliśmy owinąć jego uruchomienie w oddzielny wrapper i zabijać go po timeoutcie.
- Ansible działa na bazie procesów fork, dlatego jego API nie jest bezpieczne dla wątków. Uruchamiamy wszystkie nasze playbooki jednowątkowo.
Ostatecznie udało nam się zautomatyzować wymianę około 80% dysków. Ogólnie prędkość wymiany wzrosła dwukrotnie. Dziś administrator tylko obserwuje incydent i podejmuje decyzję, czy należy wymienić dysk, a następnie wykonuje jeden klik.
Ale teraz zaczynamy napotykać inny problem: niektórzy nowi administratorzy nie wiedzą, jak wymieniać dyski. 🙂
Źródło: habr.com
