Kiu firmware versio estas la plej "ĝusta" kaj "funkcia"? Se konserva sistemo garantias misfunkciadon de 99,9999%, ĉu tio signifas, ke ĝi funkcios seninterrompe eĉ sen programara ĝisdatigo? Aŭ, male, por akiri maksimuman toleremon al misfunkciadoj, vi ĉiam devus instali la lastan firmvaron? Ni provos respondi ĉi tiujn demandojn laŭ nia sperto.
Malgranda enkonduko
Ni ĉiuj komprenas, ke ĉiu versio de programaro, ĉu ĝi estas operaciumo aŭ pelilo por aparato, ofte enhavas difektojn/cimojn kaj aliajn "funkciojn", kiuj eble ne "aperis" ĝis la fino de la funkcidaŭro de la ekipaĵo aŭ "malfermitaj" nur sub certaj kondiĉoj. La nombro kaj signifo de tiaj nuancoj dependas de la komplekseco (funkcieco) de la programaro kaj de la kvalito de testado dum ĝia disvolviĝo.
Ofte, uzantoj restas sur la "firmvaro el la fabriko" (la fama "ĝi funkcias, do ne fuŝu kun ĝi") aŭ ĉiam instalas la lastan version (laŭ ilia kompreno, la plej nova signifas la plej funkcianta). Ni uzas malsaman aliron - ni rigardas la eldonnotojn por ĉio uzata ekipaĵo kaj zorge elektu la taŭgan firmware por ĉiu ekipaĵo.
Ni venis al ĉi tiu konkludo, kiel oni diras, kun sperto. Uzante nian ekzemplon de funkciado, ni diros al vi kial la promesita 99,9999% fidindeco de stokadsistemoj signifas nenion se vi ne senprokraste kontrolas programajn ĝisdatigojn kaj priskribojn. Nia kazo taŭgas por uzantoj de stokaj sistemoj de iu ajn vendisto, ĉar simila situacio povas okazi kun aparataro de iu ajn fabrikanto.
Elektante Novan Stokan Sistemon
Fine de la pasinta jaro, al nia infrastrukturo aldoniĝis interesa sistemo de konservado de datumoj: juniora modelo de la linio IBM FlashSystem 5000, kiu en la momento de la aĉeto nomiĝis Storwize V5010e. Nun ĝi estas vendita sub la nomo FlashSystem 5010, sed fakte ĝi estas la sama aparatara bazo kun la sama Spectrum Virtualize interne.
La ĉeesto de unuigita mastruma sistemo estas, cetere, la ĉefa diferenco inter IBM FlashSystem. Por modeloj de la pli juna serio, ĝi preskaŭ ne diferencas de modeloj de pli produktivaj. Elekti specifan modelon nur provizas la taŭgan aparataron bazon, kies karakterizaĵoj ebligas uzi unu aŭ alian funkciecon aŭ provizi pli altan nivelon de skaleblo. La programaro identigas la aparataron kaj provizas la necesan kaj sufiĉan funkciecon por ĉi tiu platformo.
IBM FlashSystem 5010
Mallonge pri nia modelo 5010. Ĉi tio estas enirnivela du-regila bloka stokado-sistemo. Ĝi povas akomodi NLSAS, SAS, SSD-diskojn. NVMe-lokigo ne haveblas en ĝi, ĉar ĉi tiu stokadmodelo estas poziciigita por solvi problemojn, kiuj ne postulas la agadon de NVMe-diskoj.
La stokadsistemo estis aĉetita por alĝustigi arkivajn informojn aŭ datumojn kiuj ne estas aliritaj ofte. Sekve, la norma aro de ĝia funkcieco sufiĉis por ni: Tiering (Easy Tier), Thin Provision. Agado sur NLSAS-diskoj je la nivelo de 1000-2000 IOPS ankaŭ estis sufiĉe kontentiga por ni.
Nia sperto - kiel ni ne ĝisdatigis la firmvaro ĝustatempe
Nun pri la programaro ĝisdatigo mem. En la momento de la aĉeto, la sistemo jam havis iomete malmodernan version de la programaro Spectrum Virtualize, nome, 8.2.1.3.
Ni studis la firmware-priskribojn kaj planis ĝisdatigon al 8.2.1.9. Se ni estus iom pli efikaj, ĉi tiu artikolo ne ekzistus - la cimo ne estus okazinta sur pli lastatempa firmvaro. Tamen, pro certaj kialoj, la ĝisdatigo de ĉi tiu sistemo estis prokrastita.
Kiel rezulto, iometa ĝisdatigo prokrasto kondukis al ekstreme malagrabla bildo, kiel en la priskribo ĉe la ligilo: .
Jes, en la firmvaro de tiu versio la tiel nomata APAR (Aŭtorizita Programa Analiza Raporto) HU02104 estis koncerna. Ĝi aperas jene. Sub ŝarĝo, sub certaj cirkonstancoj, la kaŝmemoro komencas superflui, tiam la sistemo iras en protektan reĝimon, en kiu ĝi malfunkciigas I/O por la naĝejo. En nia kazo, ĝi aspektis kiel malkonekti 3 diskojn por RAID-grupo en RAID 6-reĝimo. La malkonekto okazas dum 6 minutoj. Poste, aliro al la Volumoj en la Naĝejo estas restarigita.
Se iu ne konas la strukturon kaj nomadon de logikaj estaĵoj en la kunteksto de IBM Spectrum Virtualize, mi nun mallonge klarigos.
Strukturo de logikaj elementoj de stokado
Diskoj estas kolektitaj en grupojn nomitajn MDisk (Administrita Disko). MDisk povas esti klasika RAID (0,1,10,5,6) aŭ virtualigita - DRAID (Distribuita RAID). Uzado de DRAID permesas pliigi la rendimenton de la tabelo, ĉar... Ĉiuj diskoj en la grupo estos uzataj, kaj rekonstrua tempo reduktiĝos, pro la fakto, ke nur iuj blokoj devos esti restarigitaj, kaj ne ĉiuj datumoj de la malsukcesa disko.
Distribuado de datumblokoj tra diskoj dum uzado de Distribuita RAID (DRAID) en RAID-5-reĝimo.
Kaj ĉi tiu diagramo montras la logikon pri kiel funkcias rekonstruo de DRAID en la okazo de unu disko fiasko:
Logiko de DRAID-rekonstruo kiam unu disko malsukcesas
Poste, unu aŭ pluraj MDiskoj formas tiel nomatan Pool. Ene de la sama naĝejo, ne rekomendas uzi MDisk kun malsamaj RAID/DRAID-niveloj sur diskoj de la sama tipo. Ni ne eniros ĉi tion tro profunde, ĉar... ni planas kovri tion en unu el la sekvaj artikoloj. Nu, fakte, Pool estas dividita en Volumojn, kiuj estas prezentitaj uzante unu aŭ alian blokan alirprotokolon al la gastigantoj.
Do, ni, kiel rezulto de la situacio priskribita en APAR HU02104, pro la logika fiasko de tri diskoj, MDisk ĉesis esti funkcia, kiu, siavice, rezultigis la fiaskon de la Pool kaj la ekvivalentaj Volumoj.
Ĉar ĉi tiuj sistemoj estas sufiĉe inteligentaj, ili povas esti konektitaj al la IBM Storage Insights-nub-bazita monitoradsistemo, kiu aŭtomate sendas servopeton al IBM-subteno se problemo okazas. Aplikaĵo estas kreita kaj IBM-specialistoj malproksime faras diagnozon kaj kontaktas la sistemuzanto.
Danke al ĉi tio, la problemo estis solvita sufiĉe rapide kaj tuj ricevis rekomendon de la helpservo ĝisdatigi nian sistemon al la antaŭe elektita firmvaro 8.2.1.9, kiu tiam jam estis riparita. Ĝi konfirmas .
Rezultoj kaj niaj rekomendoj
Kiel diras la diro: "ĉio estas bone, kio bone finiĝas." La cimo en la firmvaro ne kaŭzis gravajn problemojn - la serviloj estis restarigitaj kiel eble plej baldaŭ kaj sen datumperdo. Iuj klientoj devis rekomenci virtualajn maŝinojn, sed ĝenerale ni estis pretaj por pli negativaj sekvoj, ĉar ni faras ĉiutagajn sekurkopiojn de ĉiuj infrastrukturaj elementoj kaj klientaj maŝinoj.
Ni ricevis konfirmon, ke eĉ fidindaj sistemoj kun 99,9999% promesita havebleco postulas atenton kaj ĝustatempan prizorgadon. Surbaze de la situacio, ni eltiris kelkajn konkludojn por ni mem kaj dividas niajn rekomendojn:
-
Nepras monitori la liberigon de ĝisdatigoj, studi Eldonajn Notojn por korektoj de eble kritikaj aferoj kaj efektivigi laŭplanajn ĝisdatigojn ĝustatempe.
Ĉi tio estas organiza kaj eĉ sufiĉe evidenta punkto, pri kiu, ŝajne, ne indas koncentriĝi. Tamen, sur ĉi tiu "ebena tero" vi povas tre facile stumbli. Efektive, estis ĉi tiu momento kiu aldonis la problemojn priskribitajn supre. Estu tre singarda dum ellaborado de la ĝisdatigaj regularoj kaj kontrolu la plenumon de ili ne malpli zorge. Ĉi tiu punkto rilatas pli al la koncepto de "disciplino".
-
Ĉiam estas pli bone konservi la sistemon kun la plej nova programara versio. Krome, la nuna ne estas tiu, kiu havas pli grandan nombran nomadon, sed prefere tiu kun pli posta eldondato.
Ekzemple, IBM konservas almenaŭ du programeldonojn ĝisdatigitaj por siaj stoksistemoj. En la momento de ĉi tiu skribado, ĉi tiuj estas 8.2 kaj 8.3. Ĝisdatigoj por 8.2 aperas pli frue. Simila ĝisdatigo por 8.3 estas kutime publikigita kun eta prokrasto.
Release 8.3 havas kelkajn funkciajn avantaĝojn, ekzemple, la kapablo vastigi MDisk (en DRAID-reĝimo) aldonante unu aŭ pluraj novajn diskojn (ĉi tiu funkcio aperis ekde versio 8.3.1). Ĉi tio estas sufiĉe baza funkcio, sed en 8.2, bedaŭrinde, ne ekzistas tia funkcio.
-
Se ial ne eblas ĝisdatigi, tiam por versioj de Spectrum Virtualize-programaro antaŭ versioj 8.2.1.9 kaj 8.3.1.0 (kie la supre priskribita cimo estas grava), por redukti la riskon de ĝia okazo, IBM-teknika subteno rekomendas limigante sisteman rendimenton ĉe la naĝejo, kiel montrite en la figuro malsupre (la bildo estis prenita en la Rusigita versio de la GUI). La valoro de 10000 IOPS estas montrita kiel ekzemplo kaj estas elektita laŭ la karakterizaĵoj de via sistemo.
Limigante IBM-stokan rendimenton
-
Necesas ĝuste kalkuli la ŝarĝon sur stokaj sistemoj kaj eviti troŝarĝon. Por fari tion, vi povas uzi aŭ la IBM-mezurilon (se vi havas aliron al ĝi), aŭ la helpon de partneroj, aŭ triaj rimedoj. Nepras kompreni la ŝarĝan profilon sur la stokadsistemo, ĉar Efikeco en MB/s kaj IOPS multe varias depende de almenaŭ la sekvaj parametroj:
-
operacio tipo: legi aŭ skribi,
-
grandeco de operacia bloko,
-
procento de legaj kaj skribaj operacioj en la totala I/O-rivereto.
Ankaŭ, la rapideco de operacioj estas tuŝita de kiel datumblokoj estas legitaj: sinsekve aŭ en hazarda ordo. Kiam vi faras plurajn operaciojn de aliro de datumoj ĉe la aplikaĵo, ekzistas la koncepto de dependaj operacioj. Ankaŭ estas konsilinde konsideri ĉi tion. Ĉio ĉi povas helpi vidi la totalon de datumoj de agado-nombriloj de la OS, stokado-sistemo, serviloj/hiperviziiloj, same kiel komprenon de la funkciaj funkcioj de aplikoj, DBMS-oj kaj aliaj "konsumantoj" de diskresursoj.
-
-
Kaj finfine, nepre havi sekurkopiojn ĝisdatigitajn kaj funkciantajn. La rezerva horaro devas esti agordita surbaze de akcepteblaj RPO-valoroj por la komerco, kaj periodaj integreckontroloj de la sekurkopioj devus esti kontrolitaj (tre kelkaj rezervaj softvaraj vendistoj havas aŭtomatan konfirmon efektivigitan en siaj produktoj) por certigi akcepteblan RTO-valoron.
Dankon pro legi ĝis la fino.
Ni pretas respondi viajn demandojn kaj komentojn en la komentoj. Ankaŭ, en kiu ni aranĝas regulajn promociojn (rabatoj ĉe IaaS kaj donacoj por reklamaj kodoj ĝis 100% ĉe VPS), verkas interesajn novaĵojn kaj anoncas novajn artikolojn en la blogo Habr.
fonto: www.habr.com