{"id":34841,"date":"2019-10-31T22:00:43","date_gmt":"2019-10-31T19:00:43","guid":{"rendered":"https:\/\/prohoster.info\/blog\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible\/"},"modified":"2019-10-31T22:00:43","modified_gmt":"2019-10-31T19:00:43","slug":"avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/avtomatizatsiya-zameny-diskov-s-pomoshhyu-ansible","title":{"rendered":"Automatisering af diskudskiftninger med Ansible","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Automatisering
\n
\nHej alle. Jeg arbejder som senior systemadministrator hos OK og har ansvaret for portalen's stabilitet. Jeg vil gerne fort\u00e6lle om, hvordan vi har opbygget en proces for automatisk skiftnings af harddiske, og hvordan vi derefter udelukkede administratoren fra denne proces og erstattede ham med en bot.<\/p>\n

Denne artikel er en form for transliterering foredrag<\/a><\/noindex> til HighLoad+ 2018
\n<\/a><\/noindex><\/p>\n

Opbygning af processen for skift af harddiske<\/h2>\n

<\/p>\n

F\u00f8rst nogle tal<\/h3>\n

\nOK er en gigantisk tjeneste, der bruges af millioner af mennesker. Den drives af cirka 7.000 servere, der er placeret i 4 forskellige datacentre. Serverne har over 70.000 harddiske. Hvis man l\u00e6gger dem oven p\u00e5 hinanden, f\u00e5r man et t\u00e5rn, der er over 1 km h\u00f8jt. <\/p>\n

Harddiske er den komponent i servere, der oftest svigter. Med s\u00e5danne m\u00e6ngder skal vi skifte omkring 30 diske om ugen, og denne procedure er blevet en mindre behagelig rutine.<\/p>\n

\"Automatisering
\n<\/p>\n

H\u00e6ndelser<\/h3>\n

\nI vores virksomhed er der indf\u00f8rt fuld h\u00e6ndelsesh\u00e5ndtering. Hver h\u00e6ndelse registreres i Jira, hvorefter vi l\u00f8ser og gennemg\u00e5r den. Hvis h\u00e6ndelsen havde en effekt for brugerne, samles vi og overvejer, hvordan vi hurtigt kan reagere i s\u00e5danne tilf\u00e6lde, hvordan vi kan reducere effekten, og selvf\u00f8lgelig hvordan vi kan forhindre gentagelser.<\/p>\n

Lagringsenheder er ingen undtagelse. Deres tilstand overv\u00e5ges af Zabbix. Vi monitorerer beskeder i Syslog for fejl ved skrivning\/l\u00e6sning, analyserer tilstanden af HW\/SW-RAID, overv\u00e5ger SMART, og for SSD'er beregner vi slid. <\/p>\n

Hvordan diskene blev skiftet tidligere<\/h3>\n

\nN\u00e5r der i Zabbix t\u00e6ndes for en alarm, oprettes der en h\u00e6ndelse i Jira, som automatisk tildeles de relevante ingeni\u00f8rer i datacentrene. Vi g\u00f8r dette for alle HW-h\u00e6ndelser, det vil sige s\u00e5danne, der kr\u00e6ver fysisk arbejde med udstyr i datacentret.
\nDatacenter-ingeni\u00f8ren er den person, der h\u00e5ndterer sp\u00f8rgsm\u00e5l relateret til hardware, st\u00e5r for installation, vedligeholdelse, og afmontering af servere. N\u00e5r han modtager en ticket, g\u00e5r ingeni\u00f8ren i gang. I diskkabinet skifter han selv diske. Men hvis han ikke har adgang til den n\u00f8dvendige enhed, henvender ingeni\u00f8ren sig til de vagthavende systemadministratorer for hj\u00e6lp. F\u00f8rst skal disken tages ud af rotation. For dette skal de n\u00f8dvendige \u00e6ndringer foretages p\u00e5 serveren, applikationerne stoppes, og disken afmonteres.<\/p>\n

Den vagthavende systemadministrator er ansvarlig for portalens drift i l\u00f8bet af arbejdsdagen. Han unders\u00f8ger h\u00e6ndelser, udf\u00f8rer reparationer og hj\u00e6lper udviklerne med mindre opgaver. Han besk\u00e6ftiger sig dog ikke med harddiske.<\/p>\n

Tidligere kommunikerede datacenter-ingeni\u00f8rer med systemadministratorer i chatten. Ingeni\u00f8rerne sendte links til Jira-billetter, og administratoren fulgte dem, f\u00f8rte en log over arbejdet i en eller anden notesbog. Men for s\u00e5danne opgaver er chatten upraktisk: informationen er ikke struktureret og g\u00e5r hurtigt tabt. Desuden kunne administratoren blot v\u00e6re v\u00e6k fra computeren og ikke svare p\u00e5 anmodninger i et stykke tid, mens ingeni\u00f8ren stod ved serveren med en bunke diske og ventede.<\/p>\n

Det v\u00e6rste var dog, at administratorerne ikke kunne se det store billede: hvilke diskproblemer der eksisterede, og hvor potentielle problemer kunne opst\u00e5. Dette skyldes, at vi overdrager alle HW-h\u00e6ndelser til ingeni\u00f8rerne. Ja, man kunne vise alle h\u00e6ndelser p\u00e5 administratorens dashboard. Men der er s\u00e5 mange, og administratoren blev kun involveret i nogle af dem.<\/p>\n

Derudover kunne ingeni\u00f8ren ikke korrekt prioritere, fordi han ikke vidste noget om form\u00e5let med de specifikke servere, eller hvordan informationen var fordelt p\u00e5 lagermedierne.<\/p>\n

Ny udskiftningsprocedure<\/h3>\n

\nDet f\u00f8rste, vi gjorde, var at opdele alle diskproblemer i en s\u00e6rskilt type \"HW-disk\" og tilf\u00f8je felterne \"navn p\u00e5 blokenhed\", \"st\u00f8rrelse\" og \"disktype\", s\u00e5 denne information blev gemt i billetten, og vi ikke konstant skulle udveksle den i chatten. <\/p>\n

\"Automatisering
\nVi blev ogs\u00e5 enige om, at vi kun ville udskifte \u00e9n disk inden for \u00e9n h\u00e6ndelse. Dette har v\u00e6sentligt forenklet den efterf\u00f8lgende automatiseringsproces, indsamlingen af statistik og arbejdet. <\/p>\n

Derudover tilf\u00f8jede vi feltet \"ansvarlig administrator\". Der inds\u00e6ttes automatisk den vagthavende sysadmin. Det er meget praktisk, fordi ingeni\u00f8ren altid kan se, hvem der er ansvarlig. Man beh\u00f8ver ikke at g\u00e5 ind i kalenderen og lede. Netop dette felt gjorde det muligt at vise billetter p\u00e5 administratorens dashboard, hvor hans hj\u00e6lp m\u00e5ske vil v\u00e6re n\u00f8dvendig.<\/p>\n

\"Automatisering
\nFor all participants to gain the maximum benefit from the innovations, we created filters and dashboards, and informed the team about them. When people understand the changes, they do not distance themselves from them as something unnecessary. It is important for the engineer to know the rack number where the server is located, the size and type of the disk. The administrator needs, first and foremost, to understand what group of servers this is and what effect there may be from replacing the disk.<\/p>\n

Having fields and their display is convenient, but it has not relieved us from the need to use chats. For this, we had to change the workflow. <\/p>\n

It used to be like this:<\/p>\n

\"Automatisering
\nToday, this is how engineers continue to work when they do not require the administrator's assistance.<\/p>\n

The first thing we did was introduce a new status Investigate<\/b>. In this status, the ticket is located when the engineer still hasn't decided whether they will need the administrator or not. Through this status, the engineer can pass the ticket to the administrator. Additionally, we use this status to mark tickets when a disk replacement is required, but the disk itself is not on site. This can happen in the case of CDN and remote sites.<\/p>\n

We also added a status Klar<\/b>. Tickets are transferred to this status after the disk replacement. This means everything is already done, but the HW\/SW RAID is synchronizing on the server. This can take quite a long time.<\/p>\n

If the administrator is involved in the work, the scheme becomes a bit more complicated.<\/p>\n

\"Automatisering
\nFrom the status \u00c5ben<\/b> , the ticket can be transferred by both the system administrator and the engineer. In the status In progress<\/b> , the administrator removes the disk from rotation so that the engineer can simply pull it out: they turn on the light, unmount the disk, stop applications, depending on the specific group of servers.<\/p>\n

Then the ticket is transferred to Ready to change<\/b>: this is a signal to the engineer that the disk can be pulled out. All fields in Jira are already filled in, and the engineer knows the type and size of the disk. This information is filled in either automatically in the previous status or by the administrator.<\/p>\n

After the disk replacement, the ticket is transferred to the status Changed<\/b>. It is checked that the correct disk was inserted, marking is done, the application is started, and some data recovery tasks are executed. Additionally, the ticket can be transferred to the status Klar<\/b>, in which case the administrator will remain responsible, because they registered the disk in rotation. The complete scheme looks like this.<\/p>\n

\"Automatisering
\nTilf\u00f8jelsen af nye felter har betydeligt lettet vores arbejde. Folkene arbejder nu med struktureret information, og det er blevet klart, hvad og hvorn\u00e5r der skal g\u00f8res noget. Prioriteterne er blevet langt mere relevante, da de nu fasts\u00e6ttes af administratoren.<\/p>\n

Behovet for chats er forsvundet. Selvf\u00f8lgelig kan administratoren skrive til ingeni\u00f8ren \"her skal der skiftes hurtigere\", eller \"det er allerede aften, n\u00e5r kan du skifte?\". Men vi kommunikerer ikke l\u00e6ngere dagligt i chats om disse emner.<\/p>\n

Diske skiftes nu i st\u00f8rre m\u00e6ngder. Hvis administratoren kommer lidt tidligere p\u00e5 arbejde, har han lidt tid og der er ikke opst\u00e5et noget endnu, kan han forberede en r\u00e6kke servere til udskiftning: angive felter, fjerne diske fra rotation og overdrage opgaven til ingeni\u00f8ren. Ingeni\u00f8ren kommer lidt senere til datacenteret, ser opgaven, henter de n\u00f8dvendige lagringsenheder fra lageret og skifter dem med det samme. Resultatet er, at udskiftningshastigheden er steget.<\/p>\n

Erfaringer fra opbygningen af Workflow<\/h3>\n

<\/p>\n