Cześć wszystkim. Pracuję jako wiodący administrator systemu w OK i odpowiadam za stabilne działanie portalu. Chcę porozmawiać o tym, jak zbudowaliśmy proces automatycznej wymiany dysków, a następnie jak wykluczyliśmy administratora z tego procesu i zastąpiliśmy go botem.
Ten artykuł jest rodzajem transliteracji na HighLoad+ 2018
Budowanie procesu wymiany dysku
Najpierw kilka liczb
OK to gigantyczna usługa, z której korzystają miliony ludzi. Obsługiwany jest przez około 7 tysięcy serwerów, które są zlokalizowane w 4 różnych centrach danych. Serwery zawierają ponad 70 tysięcy dysków. Jeśli ułożysz je jeden na drugim, otrzymasz wieżę o wysokości ponad 1 km.
Dyski twarde to komponent serwera, który najczęściej ulega awariom. Przy takich woluminach musimy wymieniać około 30 dysków tygodniowo, a procedura ta stała się niezbyt przyjemną rutyną.
Incydenty
Nasza firma wprowadziła kompleksowe zarządzanie incydentami. Każde zdarzenie rejestrujemy w Jira, a następnie rozwiązujemy i porządkujemy. Jeżeli incydent miał wpływ na użytkowników, to na pewno spotykamy się i zastanawiamy, jak szybciej zareagować w takich przypadkach, jak zmniejszyć skutki i oczywiście, jak zapobiec ponownemu wystąpieniu.
Urządzenia pamięci masowej nie są wyjątkiem. Ich status jest monitorowany przez Zabbix. Monitorujemy komunikaty w Syslog pod kątem błędów zapisu/odczytu, analizujemy status rajdów HW/SW, monitorujemy SMART i obliczamy zużycie dysków SSD.
Jak wcześniej wymieniano dyski
Gdy w Zabbix wystąpi wyzwalacz, w Jira tworzone jest zdarzenie i automatycznie przydzielane odpowiednim inżynierom w centrach danych. Postępujemy tak w przypadku wszystkich incydentów sprzętowych, czyli takich, które wymagają fizycznej pracy ze sprzętem w centrum danych.
Inżynier centrum danych to osoba, która rozwiązuje problemy związane ze sprzętem i jest odpowiedzialna za instalację, konserwację i demontaż serwerów. Po otrzymaniu biletu inżynier przystępuje do pracy. Na półkach dyskowych samodzielnie zmienia dyski. Jeśli jednak nie ma dostępu do wymaganego urządzenia, inżynier zwraca się o pomoc do dyżurujących administratorów systemu. Przede wszystkim musisz usunąć dysk z obrotu. W tym celu należy dokonać niezbędnych zmian na serwerze, zatrzymać aplikacje i odmontować dysk.
Za funkcjonowanie całego portalu w trakcie zmiany roboczej odpowiada dyżurujący administrator systemu. Bada incydenty, dokonuje napraw i pomaga programistom w wykonywaniu drobnych zadań. Nie zajmuje się wyłącznie dyskami twardymi.
Wcześniej inżynierowie centrum danych komunikowali się z administratorem systemu za pośrednictwem czatu. Inżynierowie przesyłali linki do zgłoszeń Jira, administrator podążał za nimi, prowadził dziennik pracy w jakimś notatniku. Jednak czaty są niewygodne w przypadku takich zadań: zawarte w nich informacje nie są uporządkowane i szybko giną. Administrator mógł po prostu odejść od komputera i przez jakiś czas nie odpowiadać na żądania, podczas gdy inżynier stał przy serwerze ze stosem dysków i czekał.
Ale najgorsze było to, że administratorzy nie widzieli całego obrazu: jakie miały miejsce zdarzenia na dysku i gdzie potencjalnie mógł pojawić się problem. Wynika to z faktu, że wszystkie incydenty sprzętowe delegujemy inżynierom. Tak, możliwe było wyświetlenie wszystkich zdarzeń na panelu administratora. Ale jest ich dużo, a administrator zajmował się tylko niektórymi z nich.
Poza tym inżynier nie potrafił poprawnie ustawić priorytetów, gdyż nie wiedział nic o przeznaczeniu konkretnych serwerów czy dystrybucji informacji pomiędzy dyskami.
Nowa procedura wymiany
Pierwszą rzeczą, którą zrobiliśmy, było przeniesienie wszystkich incydentów dyskowych do osobnego typu „dysk sprzętowy” i dodaliśmy do niego pola „nazwa urządzenia blokowego”, „rozmiar” i „typ dysku”, aby ta informacja była przechowywana w zgłoszeniu i nie nie musisz ciągle wymieniać się informacjami na czacie.
Uzgodniliśmy też, że podczas jednego incydentu wymienimy tylko jeden dysk. Znacząco uprościło to proces automatyzacji, zbierania statystyk i pracy w przyszłości.
Dodatkowo dodaliśmy pole „administrator odpowiedzialny”. Dyżurujący administrator systemu jest tam automatycznie wstawiany. Jest to bardzo wygodne, ponieważ teraz inżynier zawsze widzi, kto jest odpowiedzialny. Nie musisz iść do kalendarza i szukać. To właśnie to pole umożliwiło wyświetlenie na panelu administratora zgłoszeń, które mogły wymagać jego pomocy.
Aby wszyscy uczestnicy otrzymali maksymalne korzyści z innowacji, stworzyliśmy filtry i dashboardy i opowiedzieliśmy o nich chłopakom. Kiedy ludzie rozumieją zmiany, nie dystansują się od nich jako czegoś niepotrzebnego. Dla inżyniera ważne jest, aby znać numer szafy, w której znajduje się serwer, rozmiar i typ dysku. Administrator musi przede wszystkim zrozumieć, jakiego rodzaju jest to grupa serwerów i jaki może być skutek wymiany dysku.
Obecność pól i ich wyświetlanie jest wygodne, ale nie uchroniło nas od konieczności korzystania z czatów. Aby to zrobić, musieliśmy zmienić przepływ pracy.
Poprzednio było tak:
W ten sposób inżynierowie nadal pracują dzisiaj, gdy nie potrzebują pomocy administratora.
Pierwszą rzeczą, którą zrobiliśmy, było wprowadzenie nowego statusu Zbadać. Bilet ma ten status, gdy inżynier nie zdecydował jeszcze, czy będzie potrzebował administratora, czy nie. Dzięki temu statusowi inżynier może przekazać zgłoszenie administratorowi. Dodatkowo wykorzystujemy ten status do oznaczania zgłoszeń, gdy dysk wymaga wymiany, ale samego dysku nie ma na miejscu. Dzieje się tak w przypadku sieci CDN i witryn zdalnych.
Dodaliśmy także status Gotowy. Bilet zostaje na niego przeniesiony po wymianie dysku. Oznacza to, że wszystko zostało już zrobione, ale RAID HW/SW jest zsynchronizowany na serwerze. Może to zająć dość dużo czasu.
Jeśli w pracę zaangażowany jest administrator, schemat staje się nieco bardziej skomplikowany.
Ze statusu Otwarte Bilet może przetłumaczyć zarówno administrator systemu, jak i inżynier. W stanie w toku administrator wycofuje dysk z obrotu, aby inżynier mógł go po prostu wyciągnąć: włącza podświetlenie, odmontowuje dysk, zatrzymuje aplikacje, w zależności od konkretnej grupy serwerów.
Następnie bilet zostaje przekazany do Gotowy na zmianę: Jest to sygnał dla inżyniera, że dysk można wyciągnąć. Wszystkie pola w Jira są już wypełnione, inżynier wie jaki typ i rozmiar dysku. Dane te wprowadzane są automatycznie przy poprzednim statusie lub przez administratora.
Po wymianie dysku status biletu zmienia się na Zmieniono. Sprawdza, czy włożono właściwy dysk, wykonano partycjonowanie, uruchomiono aplikację i uruchomiono niektóre zadania odzyskiwania danych. Bilet można również przenieść do statusu Gotowy, w tym przypadku odpowiedzialność poniesie administrator, ponieważ to on włożył dysk w rotację. Kompletny schemat wygląda następująco.
Dodanie nowych pól znacznie ułatwiło nam życie. Chłopaki zaczęli pracować z ustrukturyzowanymi informacjami, stało się jasne, co należy zrobić i na jakim etapie. Priorytety stały się znacznie bardziej istotne, ponieważ są teraz ustalane przez administratora.
Nie ma potrzeby prowadzenia rozmów. Administrator może oczywiście napisać do inżyniera „trzeba to szybciej wymienić” albo „jest już wieczór, czy zdążysz to wymienić?” Ale nie komunikujemy się już codziennie na czatach na te tematy.
Dyski zaczęto zmieniać partiami. Jeśli administrator przyszedł do pracy trochę wcześniej, ma wolny czas, a jeszcze nic się nie wydarzyło, może przygotować szereg serwerów do wymiany: wypełnić pola, usunąć dyski z rotacji i przekazać zadanie inżynierowi. Inżynier przychodzi do centrum danych nieco później, widzi zadanie, pobiera z magazynu niezbędne dyski i od razu je wymienia. W efekcie wzrosła stopa zastąpienia.
Wnioski wyciągnięte podczas tworzenia Workflow
- Konstruując procedurę, musisz zebrać informacje z różnych źródeł.
Część naszych administratorów nie wiedziała, że inżynier sam wymienia dyski. Niektórzy myśleli, że synchronizacją MD RAID zajęli się inżynierowie, chociaż niektórzy z nich nawet nie mieli do tego dostępu. Niektórzy czołowi inżynierowie tak robili, ale nie zawsze, ponieważ proces ten nie został nigdzie opisany. - Procedura powinna być prosta i zrozumiała.
Trudno jest zapamiętać wiele kroków. Najważniejsze statusy sąsiadujące w Jira powinny być umieszczone na ekranie głównym. Możesz zmienić ich nazwę, na przykład nazwiemy W toku Gotowe do zmiany. Inne statusy można ukryć w rozwijanym menu, aby nie raziły w oczy. Ale lepiej nie ograniczać ludzi, dać im możliwość dokonania zmiany.
Wyjaśnij wartość innowacji. Kiedy ludzie zrozumieją, chętniej akceptują nową procedurę. Bardzo zależało nam na tym, aby ludzie nie przeklikali całego procesu, ale podążali za nim. Następnie zbudowaliśmy na tym automatyzację. - Poczekaj, przeanalizuj, wymyśl.
Zbudowanie procedury, wdrożenie techniczne, spotkania i dyskusje zajęły nam około miesiąca. A wdrożenie trwa ponad trzy miesiące. Widziałem, jak ludzie powoli zaczynają korzystać z tej innowacji. Na początku było dużo negatywnych emocji. Było to jednak całkowicie niezależne od samej procedury i jej technicznego wdrożenia. Przykładowo jeden administrator nie korzystał z Jira, ale z wtyczki Jira w Confluence i pewne rzeczy nie były dla niego dostępne. Pokazaliśmy mu Jirę i wydajność administratora wzrosła zarówno w przypadku zadań ogólnych, jak i wymiany dysków.
Automatyzacja wymiany dysku
Kilkukrotnie podchodziliśmy do automatyzacji wymiany dysków. Mieliśmy już rozwój i skrypty, ale wszystkie działały albo interaktywnie, albo ręcznie i wymagały uruchomienia. I dopiero po wprowadzeniu nowej procedury zdaliśmy sobie sprawę, że właśnie tego nam brakowało.
Ponieważ teraz nasz proces wymiany jest podzielony na etapy, z których każdy ma konkretnego wykonawcę i listę działań, możemy umożliwić automatyzację etapami, a nie wszystkimi na raz. Przykładowo najprostszy etap – Ready (sprawdzanie synchronizacji RAID/danych) można łatwo oddelegować botowi. Gdy bot już się trochę nauczy, możesz zlecić mu ważniejsze zadanie - obrócenie dysku itp.
Ustawienia zoo
Zanim porozmawiamy o bocie, wybierzmy się na krótką wycieczkę do naszego zoo instalacji. Przede wszystkim wynika to z gigantycznych rozmiarów naszej infrastruktury. Po drugie, staramy się dobrać optymalną konfigurację sprzętową dla każdej usługi. Mamy około 20 sprzętowych modeli RAID, głównie LSI i Adaptec, ale są też HP i DELL w różnych wersjach. Każdy kontroler RAID ma własne narzędzie do zarządzania. Zestaw poleceń i ich wydawanie może różnić się w zależności od wersji dla każdego kontrolera RAID. Tam, gdzie nie jest używany HW-RAID, można użyć mdraid.
Prawie wszystkie nowe instalacje wykonujemy bez tworzenia kopii zapasowej dysku. Staramy się nie używać już sprzętowej i programowej macierzy RAID, ponieważ tworzymy kopie zapasowe naszych systemów na poziomie centrum danych, a nie serwerów. Ale oczywiście istnieje wiele starszych serwerów, które wymagają obsługi.
Gdzieś dyski w kontrolerach RAID są przenoszone na urządzenia surowe, gdzieś używane są JBOD-y. Istnieją konfiguracje z jednym dyskiem systemowym w serwerze i jeśli trzeba go wymienić, to trzeba ponownie zainstalować serwer z instalacją systemu operacyjnego i aplikacji w tych samych wersjach, następnie dodać pliki konfiguracyjne, uruchomić aplikacje. Istnieje również wiele grup serwerów, w których tworzenie kopii zapasowych odbywa się nie na poziomie podsystemu dyskowego, ale bezpośrednio w samych aplikacjach.
W sumie mamy ponad 400 unikalnych grup serwerów, na których działa prawie 100 różnych aplikacji. Aby uwzględnić tak ogromną liczbę opcji, potrzebowaliśmy wielofunkcyjnego narzędzia do automatyzacji. Najlepiej z prostym DSL, żeby nie tylko osoba, która to napisała mogła to obsłużyć.
Wybraliśmy Ansible, ponieważ jest on bezagentowy: nie było potrzeby przygotowywania infrastruktury, szybki start. Dodatkowo jest napisany w języku Python, co jest akceptowane w zespole jako standard.
Schemat ogólny
Przyjrzyjmy się ogólnemu schematowi automatyzacji na przykładzie jednego zdarzenia. Zabbix wykrywa awarię dysku sdb, zapala się wyzwalacz i w Jira tworzony jest bilet. Administrator spojrzał na to, zdał sobie sprawę, że nie jest to duplikat ani fałszywy alarm, to znaczy dysk wymaga wymiany, i przeniósł zgłoszenie do W toku.
Aplikacja DiskoBot napisana w Pythonie okresowo odpytuje Jirę o nowe zgłoszenia. Zauważa, że pojawił się nowy bilet W toku, uruchamiany jest odpowiedni wątek, który uruchamia playbook w Ansible (odbywa się to dla każdego statusu w Jira). W takim przypadku zostanie uruchomione Przygotowanie2change.
Ansible jest wysyłany do hosta, usuwa dysk z rotacji i raportuje stan do aplikacji poprzez wywołania zwrotne.
Na podstawie wyników bot automatycznie przekazuje zgłoszenie do stanu Gotowy do zmiany. Inżynier otrzymuje powiadomienie i udaje się na wymianę dysku, po czym przekazuje bilet do Zmieniony.
Według schematu opisanego powyżej bilet wraca do bota, który uruchamia kolejny playbook, trafia do hosta i wprawia dysk w rotację. Bot zamyka zgłoszenie. Brawo!
Porozmawiajmy teraz o niektórych elementach systemu.
Dyskbot
Ta aplikacja jest napisana w języku Python. Wybiera bilety z Jira według JQL. W zależności od statusu biletu, ten ostatni trafia do odpowiedniego modułu obsługi, który z kolei uruchamia podręcznik Ansible odpowiadający temu statusowi.
JQL i interwały odpytywania są zdefiniowane w pliku konfiguracyjnym aplikacji.
jira_states:
investigate:
jql: '… status = Open and "Disk Size" is EMPTY'
interval: 180
inprogress:
jql: '… and "Disk Size" is not EMPTY and "Device Name" is not EMPTY'
ready:
jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)'
interval: 7200
Przykładowo spośród zgłoszeń o statusie W toku wybierane są tylko te, które mają wypełnione pola Rozmiar dysku i Nazwa urządzenia. Nazwa urządzenia to nazwa urządzenia blokowego potrzebnego do wykonania podręcznika. Rozmiar dysku jest potrzebny, aby inżynier wiedział, jaki rozmiar dysku jest potrzebny.
Wśród zgłoszeń o statusie Gotowe odfiltrowywane są zgłoszenia z etykietą dbot_ignore. Nawiasem mówiąc, etykiet Jira używamy zarówno do takiego filtrowania, jak i do oznaczania zduplikowanych zgłoszeń i zbierania statystyk.
Jeśli podręcznik zakończy się niepowodzeniem, Jira przypisze etykietę dbot_failed, aby można było później rozwiązać problem.
Interoperacyjność z Ansible
Aplikacja komunikuje się z Ansible poprzez . Do playbook_executor przekazujemy nazwę pliku i zestaw zmiennych. Dzięki temu możesz zachować projekt Ansible w postaci zwykłych plików yml, zamiast opisywać go w kodzie Pythona.
Również w Ansible, poprzez *extra_vars*, nazwę urządzenia blokowego, status biletu, a także callback_url, który zawiera klucz wydania - służy do wywołania zwrotnego w HTTP.
Dla każdego uruchomienia generowany jest tymczasowy inwentarz składający się z jednego hosta i grupy, do której ten host należy, tak aby stosowane były group_vars.
Oto przykład zadania, które implementuje wywołanie zwrotne HTTP.
Otrzymujemy wynik wykonywania playbooków za pomocą wywołań zwrotnych. Są dwojakiego rodzaju:
- , dostarcza danych o wynikach wykonania playbooka. Opisuje zadania, które zostały rozpoczęte, zakończone sukcesem lub niepowodzeniem. To wywołanie zwrotne jest wywoływane po zakończeniu odtwarzania podręcznika.
- Wywołanie zwrotne HTTP w celu otrzymania informacji podczas odtwarzania podręcznika. W zadaniu Ansible wykonujemy żądanie POST/GET do naszej aplikacji.
Zmienne są przekazywane poprzez wywołania zwrotne HTTP, które zostały zdefiniowane podczas wykonywania podręcznika i które chcemy zapisać i wykorzystać w kolejnych uruchomieniach. Zapisujemy te dane w sqlite.
Zostawiamy również komentarze i zmieniamy status zgłoszenia poprzez wywołanie zwrotne HTTP.
Wywołanie zwrotne HTTP
# 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 zadań tego samego typu, umieszczamy je w osobnym wspólnym pliku i dołączamy w razie potrzeby, aby nie powtarzać ich ciągle w playbookach. Obejmuje to adres URL wywołania zwrotnego, który zawiera klucz problemu i nazwę hosta. Kiedy Ansible wykonuje to żądanie POST, bot rozumie, że pojawiło się ono w ramach takiego a takiego zdarzenia.
A oto przykład z podręcznika, w którym wyprowadzamy 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 przenosi zgłoszenie Jira do stanu „Gotowy do zmiany” i dodaje komentarz. Ponadto zmienna mdam_data przechowuje listę urządzeń md, z których usunięto dysk, a parted_info przechowuje zrzut partycji z parted.
Gdy inżynier wstawi nowy dysk, możemy użyć tych zmiennych do przywrócenia zrzutu partycji, a także włożyć dysk do urządzeń md, z których został usunięty.
Tryb sprawdzania Ansible
Strach było włączyć automatykę. Dlatego zdecydowaliśmy się uruchomić wszystkie podręczniki w tym trybie
, w którym Ansible nie wykonuje żadnych akcji na serwerach, a jedynie je emuluje.
Takie uruchomienie przeprowadzane jest poprzez osobny moduł wywołania zwrotnego, a wynik wykonania playbooka zapisywany jest w Jira jako komentarz.
Po pierwsze, umożliwiło to walidację pracy bota i playbooków. Po drugie, zwiększyło to zaufanie administratorów do bota.
Kiedy pomyślnie przeszliśmy weryfikację i zdaliśmy sobie sprawę, że Ansible można uruchomić nie tylko w trybie próbnym, utworzyliśmy przycisk Uruchom Diskobot w Jira, aby uruchomić ten sam podręcznik z tymi samymi zmiennymi na tym samym hoście, ale w trybie normalnym.
Ponadto przycisk służy do ponownego uruchomienia podręcznika w przypadku awarii.
Struktura podręczników
Wspomniałem już, że w zależności od statusu zgłoszenia w Jirze bot uruchamia różne playbooki.
Po pierwsze, znacznie łatwiej jest zorganizować wejście.
Po drugie, w niektórych przypadkach jest to po prostu konieczne.
Przykładowo przy wymianie dysku systemowego należy najpierw udać się do systemu wdrożeniowego, utworzyć zadanie, a po prawidłowym wdrożeniu serwer stanie się dostępny poprzez ssh i będzie można na nim wgrać aplikację. Gdybyśmy zrobili to wszystko w jednym podręczniku, Ansible nie byłby w stanie tego ukończyć ze względu na niedostępność hosta.
Dla każdej grupy serwerów używamy ról Ansible. Tutaj możesz zobaczyć, jak podręczniki są zorganizowane w jednym z nich.
Jest to wygodne, ponieważ od razu wiadomo, gdzie znajdują się zadania. W pliku main.yml, który jest wejściem dla roli Ansible, możemy po prostu uwzględnić status biletu lub ogólne zadania wymagane dla wszystkich, na przykład przekazanie identyfikacji lub otrzymanie tokena.
Dochodzenie.yml
Biega po bilety w statusie Dochodzenie i Otwarte. Najważniejszą rzeczą w tym podręczniku jest nazwa urządzenia blokowego. Informacje te nie zawsze są dostępne.
Aby to uzyskać, analizujemy podsumowanie Jira, ostatnią wartość z wyzwalacza Zabbix. Może zawierać nazwę urządzenia blokowego - szczęście. Lub może zawierać punkt podłączenia, wtedy musisz udać się do serwera, przeanalizować go i obliczyć wymagany dysk. Wyzwalacz może także przesyłać adres SCSI lub inne informacje. Ale zdarza się też, że nie ma żadnych wskazówek i trzeba analizować.
Po ustaleniu nazwy urządzenia blokowego zbieramy z niego informacje o typie i rozmiarze dysku, aby wypełnić pola w Jira. Usuwamy również informacje o dostawcy, modelu, oprogramowaniu sprzętowym, identyfikatorze, SMART i umieszczamy to wszystko w komentarzu w zgłoszeniu Jira. Administrator i inżynier nie muszą już szukać tych danych. 🙂
przygotuj2zmiana.yml
Wyjmowanie dysku z obrotu, przygotowanie do wymiany. Najtrudniejszy i najważniejszy etap. W tym miejscu możesz zatrzymać aplikację, gdy nie powinna być zatrzymywana. Lub wyjmij dysk, na którym nie było wystarczającej liczby replik, co spowoduje utratę części danych przez użytkowników. Tutaj mamy najwięcej kontroli i powiadomień na czacie.
W najprostszym przypadku mówimy o usunięciu dysku z macierzy RAID HW/MD.
W bardziej skomplikowanych sytuacjach (w naszych systemach dyskowych), gdy kopia zapasowa wykonywana jest na poziomie aplikacji, należy przejść do aplikacji przez API, zgłosić wyjście dysku, dezaktywować go i rozpocząć odzyskiwanie.
Obecnie przeprowadzamy masową migrację do , a jeśli serwer jest oparty na chmurze, Diskobot wywołuje API chmury, mówi, że będzie działać z tym sługusem – serwerem, na którym działają kontenery – i pyta „przeprowadź migrację wszystkich kontenerów z tego sługusa”. Jednocześnie włącza podświetlenie dysku, dzięki czemu inżynier od razu widzi, który należy wyciągnąć.
zmieniony.yml
Po wymianie dysku w pierwszej kolejności sprawdzamy jego dostępność.
Inżynierowie nie zawsze instalują nowe dyski, dlatego dodaliśmy sprawdzenie wartości SMART, które nas zadowalają.
Na jakie atrybuty zwracamy uwagę?Liczba przeniesionych sektorów (5) < 100
Bieżąca liczba oczekujących sektorów (107) == 0
Jeżeli dysk nie przejdzie pomyślnie testu, inżynier zostaje powiadomiony o konieczności jego ponownej wymiany. Jeśli wszystko jest w porządku, podświetlenie zostaje wyłączone, nanoszone są oznaczenia i płyta zostaje wprawiona w ruch obrotowy.
gotowy.yml
Najprostszy przypadek: sprawdzenie synchronizacji raidów HW/SW lub dokończenie synchronizacji danych w aplikacji.
API aplikacji
Już kilkukrotnie wspominałem, że bot często uzyskuje dostęp do API aplikacji. Oczywiście nie wszystkie aplikacje posiadały niezbędne metody, więc trzeba było je modyfikować. Oto najważniejsze metody, z których korzystamy:
- Status. Status klastra lub dysku, aby zrozumieć, czy można z nim pracować;
- Zacząć zakończyć. Aktywacja/dezaktywacja dysku;
- Przeprowadź migrację/przywróć. Migracja i odzyskiwanie danych w trakcie i po wymianie.
Wnioski wyciągnięte z Ansible
Bardzo lubię Ansible. Ale często, gdy patrzę na różne projekty open source i widzę, jak ludzie piszą podręczniki, trochę się boję. Złożone logiczne sploty kiedy/pętli, brak elastyczności i idempotencji ze względu na częste używanie powłoki/poleceń.
Postanowiliśmy wszystko maksymalnie uprościć, wykorzystując zaletę Ansible – modułowość. Na najwyższym poziomie znajdują się playbooki, które może napisać każdy administrator, zewnętrzny programista, który zna trochę Ansible.
- name: Blink disk
become: True
register: locate_action
disk_locate:
locate: '{{ locate }}'
devname: '{{ devname }}'
ids: '{{ locate_ids | default(pd_id) | default(omit) }}'
Jeśli jakaś logika jest trudna do wdrożenia w podręcznikach, przenosimy ją do modułu lub filtra Ansible. Skrypty można pisać w Pythonie lub dowolnym innym języku.
Pisze się je łatwo i szybko. Na przykład moduł podświetlenia dysku, którego przykład pokazano powyżej, składa się z 265 linii.
Na najniższym poziomie znajduje się biblioteka. Na potrzeby tego projektu napisaliśmy osobną aplikację, swego rodzaju abstrakcję nad sprzętowymi i programowymi RAIDami, które realizują odpowiednie żądania.
Największą zaletą Ansible jest prostota i przejrzyste schematy działania. Uważam, że musisz tego użyć i nie generować strasznych plików YAML i ogromnej liczby warunków, kodu powłoki i pętli.
Jeśli chcesz powtórzyć nasze doświadczenia z Ansible API, pamiętaj o dwóch rzeczach:
- Playbook_executor i ogólnie playbooki nie mogą mieć limitu czasu. Upłynął limit czasu sesji ssh, ale nie ma limitu czasu w podręczniku. Jeśli spróbujemy odmontować dysk, którego już nie ma w systemie, podręcznik będzie działał w nieskończoność, więc musieliśmy zawinąć jego uruchomienie w osobne opakowanie i zabić go limitem czasu.
- Ansible działa na rozwidlonych procesach, więc jego API nie jest bezpieczne dla wątków. Wszystkie nasze podręczniki uruchamiamy w trybie jednowątkowym.
Dzięki temu udało nam się zautomatyzować wymianę około 80% dysków. Ogólnie rzecz biorąc, stopa zastąpienia wzrosła dwukrotnie. Dzisiaj administrator po prostu przygląda się zdarzeniu i decyduje, czy dysk wymaga wymiany, czy nie, a następnie wykonuje jedno kliknięcie.
Ale teraz zaczynamy napotykać inny problem: niektórzy nowi administratorzy nie wiedzą, jak zmieniać dyski. 🙂
Źródło: www.habr.com