Aling bersyon ng firmware ang pinaka "tama" at "gumagana"? Kung ginagarantiyahan ng isang storage system ang fault tolerance na 99,9999%, ibig sabihin ba nito ay gagana ito nang walang patid kahit na walang pag-update ng software? O, sa kabaligtaran, upang makakuha ng maximum na fault tolerance, dapat mong palaging i-install ang pinakabagong firmware? Susubukan naming sagutin ang mga tanong na ito batay sa aming karanasan.
Isang maliit na pagpapakilala
Naiintindihan nating lahat na ang bawat bersyon ng software, ito man ay isang operating system o isang driver para sa isang device, ay kadalasang naglalaman ng mga depekto/mga bug at iba pang "mga tampok" na maaaring hindi "lumitaw" hanggang sa katapusan ng buhay ng serbisyo ng kagamitan, o "bukas" sa ilalim lamang ng ilang mga kundisyon. Ang bilang at kahalagahan ng naturang mga nuances ay nakasalalay sa pagiging kumplikado (functionality) ng software at sa kalidad ng pagsubok sa panahon ng pagbuo nito.
Kadalasan, ang mga gumagamit ay nananatili sa "firmware mula sa pabrika" (ang sikat na "gumagana ito, kaya huwag guluhin ito") o palaging i-install ang pinakabagong bersyon (sa kanilang pag-unawa, ang pinakahuling nangangahulugang ang pinaka gumagana). Gumagamit kami ng ibang diskarte - tinitingnan namin ang mga tala sa paglabas para sa lahat ng ginamit kagamitan at maingat na piliin ang naaangkop na firmware para sa bawat piraso ng kagamitan.
Nakarating kami sa konklusyong ito, tulad ng sinasabi nila, na may karanasan. Gamit ang aming halimbawa ng pagpapatakbo, sasabihin namin sa iyo kung bakit walang ibig sabihin ang ipinangakong 99,9999% na pagiging maaasahan ng mga storage system kung hindi mo agad susubaybayan ang mga update at paglalarawan ng software. Ang aming kaso ay angkop para sa mga gumagamit ng mga sistema ng imbakan mula sa anumang vendor, dahil ang isang katulad na sitwasyon ay maaaring mangyari sa hardware mula sa anumang tagagawa.
Pagpili ng Bagong Storage System
Sa pagtatapos ng nakaraang taon, isang kawili-wiling sistema ng pag-iimbak ng data ang idinagdag sa aming imprastraktura: isang junior model mula sa linya ng IBM FlashSystem 5000, na sa oras ng pagbili ay tinawag na Storwize V5010e. Ngayon ito ay ibinebenta sa ilalim ng pangalang FlashSystem 5010, ngunit sa katunayan ito ay ang parehong hardware base na may parehong Spectrum Virtualize sa loob.
Ang pagkakaroon ng isang pinag-isang sistema ng pamamahala ay, sa pamamagitan ng paraan, ang pangunahing pagkakaiba sa pagitan ng IBM FlashSystem. Para sa mga modelo ng mas batang serye, halos hindi ito naiiba sa mga modelo ng mas produktibo. Ang pagpili ng isang partikular na modelo ay nagbibigay lamang ng naaangkop na base ng hardware, ang mga katangian nito ay ginagawang posible na gumamit ng isa o ibang functionality o magbigay ng mas mataas na antas ng scalability. Kinikilala ng software ang hardware at nagbibigay ng kinakailangan at sapat na functionality para sa platform na ito.
IBM FlashSystem 5010
Sa madaling sabi tungkol sa aming modelong 5010. Ito ay isang entry-level na dual-controller block storage system. Maaari itong tumanggap ng mga disk ng NLSAS, SAS, SSD. Ang paglalagay ng NVMe ay hindi magagamit dito, dahil ang modelo ng imbakan na ito ay nakaposisyon upang malutas ang mga problema na hindi nangangailangan ng pagganap ng mga NVMe drive.
Ang sistema ng imbakan ay binili upang mapaunlakan ang impormasyon ng archival o data na hindi naa-access nang madalas. Samakatuwid, sapat na para sa amin ang karaniwang hanay ng functionality nito: Tiering (Easy Tier), Thin Provision. Ang pagganap sa mga disk ng NLSAS sa antas na 1000-2000 IOPS ay medyo kasiya-siya din para sa amin.
Ang aming karanasan - kung paano hindi namin na-update ang firmware sa oras
Ngayon tungkol sa pag-update ng software mismo. Sa oras ng pagbili, ang system ay mayroon nang bahagyang hindi napapanahong bersyon ng Spectrum Virtualize software, ibig sabihin, 8.2.1.3.
Pinag-aralan namin ang mga paglalarawan ng firmware at nagplano ng pag-update sa 8.2.1.9. Kung naging mas mahusay kami ng kaunti, hindi na sana umiral ang artikulong ito - hindi sana nangyari ang bug sa isang mas kamakailang firmware. Gayunpaman, para sa ilang mga kadahilanan, ang pag-update ng system na ito ay ipinagpaliban.
Bilang resulta, ang isang bahagyang pagkaantala sa pag-update ay humantong sa isang hindi kasiya-siyang larawan, tulad ng sa paglalarawan sa link: .
Oo, sa firmware ng bersyon na iyon ang tinatawag na APAR (Authorized Program Analysis Report) HU02104 ay may kaugnayan. Lumilitaw ang mga sumusunod. Sa ilalim ng pag-load, sa ilalim ng ilang mga pangyayari, ang cache ay nagsisimulang umapaw, pagkatapos ang system ay napupunta sa proteksiyon na mode, kung saan hindi pinagana nito ang I/O para sa pool. Sa aming kaso, mukhang dinidiskonekta ang 3 disk para sa isang pangkat ng RAID sa mode na RAID 6. Nagaganap ang pagdiskonekta sa loob ng 6 na minuto. Susunod, ang pag-access sa Mga Volume sa Pool ay naibalik.
Kung sinuman ang hindi pamilyar sa istruktura at pagpapangalan ng mga lohikal na entity sa konteksto ng IBM Spectrum Virtualize, maikli kong ipapaliwanag ngayon.
Istraktura ng mga lohikal na elemento ng sistema ng imbakan
Ang mga disk ay kinokolekta sa mga pangkat na tinatawag na MDisk (Managed Disk). Ang MDisk ay maaaring isang klasikong RAID (0,1,10,5,6) o isang virtualized - DRAID (Distributed RAID). Ang paggamit ng DRAID ay nagbibigay-daan sa iyo upang mapataas ang pagganap ng array, dahil... Gagamitin ang lahat ng mga disk sa grupo, at mababawasan ang oras ng muling pagtatayo, dahil sa ang katunayan na ang ilang mga bloke lamang ang kailangang maibalik, at hindi lahat ng data mula sa nabigong disk.
Pamamahagi ng mga bloke ng data sa mga disk kapag gumagamit ng Distributed RAID (DRAID) sa RAID-5 mode.
At ang diagram na ito ay nagpapakita ng lohika kung paano gumagana ang isang DRAID rebuild sa kaganapan ng isang disk failure:
Logic ng DRAID rebuild kapag nabigo ang isang disk
Susunod, ang isa o higit pang MDisks ay bumubuo ng tinatawag na Pool. Sa loob ng parehong pool, hindi inirerekomenda na gumamit ng MDisk na may iba't ibang antas ng RAID/DRAID sa mga disk ng parehong uri. Hindi natin ito tatalakayin nang malalim, dahil... plano naming pag-usapan ito sa isa sa mga sumusunod na artikulo. Sa katunayan, ang Pool ay nahahati sa Mga Volume, na ipinakita gamit ang isa o isa pang block access protocol sa mga host.
Kaya, kami, bilang resulta ng sitwasyong inilarawan sa APAR HU02104, dahil sa lohikal na kabiguan ng tatlong mga disk, ang MDisk ay tumigil sa paggana, na, sa turn, ay nagresulta sa pagkabigo ng Pool at ang kaukulang mga Volume.
Dahil medyo matalino ang mga system na ito, maaari silang ikonekta sa cloud-based na monitoring system ng IBM Storage Insights, na awtomatikong nagpapadala ng kahilingan sa serbisyo sa suporta ng IBM kung may nangyaring problema. Ang isang application ay nilikha at ang mga espesyalista ng IBM ay malayong nagsasagawa ng mga diagnostic at makipag-ugnayan sa user ng system.
Dahil dito, medyo mabilis na nalutas ang isyu at natanggap ang isang agarang rekomendasyon mula sa serbisyo ng suporta upang i-update ang aming system sa dating napiling firmware na 8.2.1.9, na sa oras na iyon ay naayos na. Kinukumpirma nito .
Mga resulta at aming mga rekomendasyon
Sabi nga sa kasabihan: "all's well that ends well." Ang bug sa firmware ay hindi naging sanhi ng malubhang problema - ang mga server ay naibalik sa lalong madaling panahon at walang pagkawala ng data. Kinailangang i-restart ng ilang kliyente ang mga virtual machine, ngunit sa pangkalahatan ay handa kami para sa higit pang mga negatibong kahihinatnan, dahil gumagawa kami ng pang-araw-araw na pag-backup ng lahat ng elemento ng imprastraktura at mga makina ng kliyente.
Nakatanggap kami ng kumpirmasyon na kahit na ang mga maaasahang system na may 99,9999% na ipinangakong availability ay nangangailangan ng pansin at napapanahong pagpapanatili. Batay sa sitwasyon, gumawa kami ng ilang mga konklusyon para sa aming sarili at ibinahagi ang aming mga rekomendasyon:
-
Kinakailangang subaybayan ang pagpapalabas ng mga update, pag-aralan ang Mga Tala sa Paglabas para sa mga pagwawasto ng mga potensyal na kritikal na isyu, at isagawa ang mga nakaplanong update sa isang napapanahong paraan.
Ito ay isang pang-organisasyon at kahit na medyo malinaw na punto, na, tila, ay hindi nagkakahalaga ng pagtuon sa. Gayunpaman, sa "level na lupa" na ito ay madali kang madapa. Sa totoo lang, ang sandaling ito ang nagdagdag ng mga problemang inilarawan sa itaas. Maging napaka-ingat sa pagbuo ng mga regulasyon sa pag-update at subaybayan ang pagsunod sa mga ito nang hindi gaanong maingat. Ang puntong ito ay higit na nauugnay sa konsepto ng "disiplina".
-
Laging mas mainam na panatilihin ang system gamit ang pinakabagong bersyon ng software. Bukod dito, ang kasalukuyang isa ay hindi ang isa na may mas malaking de-numerong pagtatalaga, ngunit sa halip ang isa na may mas huling petsa ng paglabas.
Halimbawa, pinapanatili ng IBM ang hindi bababa sa dalawang release ng software na napapanahon para sa mga storage system nito. Sa oras ng pagsulat na ito, ang mga ito ay 8.2 at 8.3. Ang mga update para sa 8.2 ay lumabas nang mas maaga. Ang isang katulad na update para sa 8.3 ay karaniwang inilabas na may bahagyang pagkaantala.
Ang Release 8.3 ay may isang bilang ng mga functional na pakinabang, halimbawa, ang kakayahang palawakin ang MDisk (sa DRAID mode) sa pamamagitan ng pagdaragdag ng isa o higit pang mga bagong disk (ang tampok na ito ay lumitaw mula noong bersyon 8.3.1). Ito ay isang medyo pangunahing pag-andar, ngunit sa 8.2, sa kasamaang-palad, walang ganoong tampok.
-
Kung hindi posible na mag-update para sa ilang kadahilanan, pagkatapos ay para sa mga bersyon ng Spectrum Virtualize software bago ang mga bersyon 8.2.1.9 at 8.3.1.0 (kung saan ang bug na inilarawan sa itaas ay may kaugnayan), upang mabawasan ang panganib ng paglitaw nito, inirerekomenda ng IBM technical support nililimitahan ang pagganap ng system sa antas ng pool, tulad ng ipinapakita sa figure sa ibaba (ang larawan ay kinuha sa Russified na bersyon ng GUI). Ang halaga ng 10000 IOPS ay ipinapakita bilang isang halimbawa at pinili ayon sa mga katangian ng iyong system.
Nililimitahan ang pagganap ng storage ng IBM
-
Kinakailangan na wastong kalkulahin ang pagkarga sa mga sistema ng imbakan at maiwasan ang labis na karga. Upang gawin ito, maaari mong gamitin ang alinman sa IBM sizer (kung mayroon kang access dito), o ang tulong ng mga kasosyo, o mga mapagkukunan ng third-party. Mahalagang maunawaan ang profile ng pagkarga sa sistema ng imbakan, dahil Malaki ang pagkakaiba ng performance sa MB/s at IOPS depende sa hindi bababa sa mga sumusunod na parameter:
-
uri ng operasyon: basahin o isulat,
-
laki ng bloke ng operasyon,
-
porsyento ng read at write na mga operasyon sa kabuuang I/O stream.
Gayundin, ang bilis ng mga operasyon ay apektado ng kung paano binabasa ang mga bloke ng data: sunud-sunod o sa random na pagkakasunud-sunod. Kapag nagsasagawa ng maraming operasyon sa pag-access ng data sa panig ng aplikasyon, mayroong konsepto ng mga umaasang operasyon. Maipapayo rin na isaalang-alang ito. Ang lahat ng ito ay makakatulong upang makita ang kabuuan ng data mula sa mga performance counter ng OS, storage system, server/hypervisor, pati na rin ang pag-unawa sa mga operating feature ng mga application, DBMS at iba pang "consumer" ng disk resources.
-
-
At sa wakas, siguraduhing magkaroon ng mga backup na napapanahon at gumagana. Ang iskedyul ng pag-backup ay dapat na i-configure batay sa mga katanggap-tanggap na halaga ng RPO para sa negosyo, at ang mga pana-panahong pagsusuri sa integridad ng mga backup ay dapat na ma-verify (medyo ilang backup na software vendor ang may automated na pag-verify na ipinatupad sa kanilang mga produkto) upang matiyak ang isang katanggap-tanggap na halaga ng RTO.
Salamat sa pagbabasa hanggang dulo.
Handa kaming sagutin ang iyong mga katanungan at komento sa mga komento. Gayundin, kung saan nagtataglay kami ng mga regular na promosyon (mga diskwento sa IaaS at mga pamigay para sa mga code na pang-promosyon hanggang 100% sa VPS), magsulat ng mga kawili-wiling balita at mag-anunsyo ng mga bagong artikulo sa Habr blog.
Pinagmulan: www.habr.com