Mikä laiteohjelmistoversio on "oikein" ja "toimivin"? Jos tallennusjärjestelmä takaa 99,9999 %:n vikasietokyvyn, tarkoittaako se, että se toimii keskeytyksettä myös ilman ohjelmistopäivitystä? Tai päinvastoin, parhaan mahdollisen vikasietokyvyn saavuttamiseksi sinun tulee aina asentaa uusin laiteohjelmisto? Yritämme vastata näihin kysymyksiin kokemuksemme perusteella.
Pieni johdanto
Ymmärrämme kaikki, että jokainen ohjelmistoversio, olipa kyseessä sitten käyttöjärjestelmä tai laitteen ohjain, sisältää usein vikoja/virheitä ja muita "ominaisuuksia", jotka eivät ehkä "ilmenne" ennen laitteen käyttöiän päättymistä tai "auki". vain tietyin edellytyksin. Tällaisten vivahteiden määrä ja merkitys riippuu ohjelmiston monimutkaisuudesta (toiminnallisuudesta) ja sen kehitysvaiheen testauksen laadusta.
Usein käyttäjät pysyvät "tehdasohjelmistossa" (kuuluisa "se toimii, joten älä sotke sitä") tai asentavat aina uusimman version (heidän ymmärryksensä mukaan uusin tarkoittaa toimivinta). Käytämme erilaista lähestymistapaa - katsomme kaiken käytetyn julkaisutiedot laitteet ja valitse huolellisesti kullekin laitteelle sopiva laiteohjelmisto.
Päädyimme tähän johtopäätökseen, kuten he sanovat, kokemuksella. Toimintaesimerkkimme avulla kerromme, miksi tallennusjärjestelmien luvattu 99,9999 %:n luotettavuus ei tarkoita mitään, jos ohjelmistopäivityksiä ja kuvauksia ei valvota ripeästi. Kotelomme sopii minkä tahansa valmistajan tallennusjärjestelmien käyttäjille, koska samanlainen tilanne voi tapahtua minkä tahansa valmistajan laitteiston kanssa.
Uuden tallennusjärjestelmän valinta
Viime vuoden lopulla infrastruktuuriamme lisättiin mielenkiintoinen tiedontallennusjärjestelmä: IBM FlashSystem 5000 -sarjan juniorimalli, jonka nimi oli ostohetkellä Storwize V5010e. Nyt sitä myydään nimellä FlashSystem 5010, mutta itse asiassa se on sama laitteistokanta, jonka sisällä on sama Spectrum Virtualize.
Yhtenäisen hallintajärjestelmän olemassaolo on muuten tärkein ero IBM FlashSystemin välillä. Nuoremman sarjan malleissa se ei käytännössä eroa tuottavampien mallien malleista. Tietyn mallin valinta tarjoaa vain sopivan laitteistopohjan, jonka ominaisuudet mahdollistavat yhden tai toisen toiminnallisuuden käytön tai tarjoavat korkeamman skaalautuvuuden. Ohjelmisto tunnistaa laitteiston ja tarjoaa tarvittavat ja riittävät toiminnot tälle alustalle.
IBM FlashSystem 5010
Lyhyesti mallistamme 5010. Tämä on kahden ohjaimen lähtötason tallennusjärjestelmä. Se mahtuu NLSAS-, SAS- ja SSD-levyille. NVMe-sijoitus ei ole käytettävissä siinä, koska tämä tallennusmalli on sijoitettu ratkaisemaan ongelmia, jotka eivät vaadi NVMe-asemien suorituskykyä.
Tallennusjärjestelmä ostettiin arkistointitietojen tai harvoin käytettyjen tietojen säilyttämiseksi. Siksi sen toiminnallisuuden vakiosarja riitti meille: Tiering (Easy Tier), Thin Provision. Myös NLSAS-levyjen suorituskyky 1000-2000 IOPS:n tasolla oli meille varsin tyydyttävä.
Kokemuksemme - kuinka emme päivittäneet laiteohjelmistoa ajoissa
Nyt itse ohjelmistopäivityksestä. Järjestelmässä oli ostohetkellä jo hieman vanhentunut versio Spectrum Virtualize -ohjelmistosta, nimittäin 8.2.1.3.
Tutkimme laiteohjelmiston kuvauksia ja suunnittelimme päivityksen 8.2.1.9. Jos olisimme olleet hieman tehokkaampia, tätä artikkelia ei olisi ollut olemassa – virhettä ei olisi tapahtunut uudemmassa laiteohjelmistossa. Tietyistä syistä tämän järjestelmän päivitystä kuitenkin lykättiin.
Tämän seurauksena pieni päivitysviive johti erittäin epämiellyttävään kuvaan, kuten linkin kuvauksessa: .
Kyllä, kyseisen version laiteohjelmistossa niin sanottu APAR (Authorized Program Analysis Report) HU02104 oli relevantti. Se näyttää seuraavalta. Kuormituksen alaisena, tietyissä olosuhteissa, välimuisti alkaa vuotaa yli, minkä jälkeen järjestelmä siirtyy suojaustilaan, jossa se poistaa I/O-varannon käytöstä. Meidän tapauksessamme se näytti siltä, että RAID-ryhmää varten olisi irrotettu 3 levyä RAID 6 -tilassa.Katkaisu tapahtuu 6 minuutin ajan. Seuraavaksi pääsy altaan volyymeihin palautetaan.
Jos joku ei tunne loogisten entiteettien rakennetta ja nimeämistä IBM Spectrum Virtualizen kontekstissa, selitän nyt lyhyesti.
Tallennusjärjestelmän loogisten elementtien rakenne
Levyt kootaan ryhmiin nimeltä MDisk (Managed Disk). MDisk voi olla klassinen RAID (0,1,10,5,6) tai virtualisoitu - DRAID (Distributed RAID). DRAIDin avulla voit lisätä taulukon suorituskykyä, koska... Kaikkia ryhmän levyjä käytetään, ja uudelleenrakennusaika lyhenee, koska vain tietyt lohkot on palautettava, ei kaikkia viallisen levyn tietoja.
Tietolohkojen jakautuminen levyille käytettäessä Distributed RAID (DRAID) -tekniikkaa RAID-5-tilassa.
Ja tämä kaavio näyttää logiikan, kuinka DRAID-uudelleenrakennus toimii yhden levyvian sattuessa:
DRAID-uudelleenmuodostuksen logiikka, kun yksi levy epäonnistuu
Seuraavaksi yksi tai useampi MDiski muodostaa niin kutsutun poolin. Samassa poolissa ei ole suositeltavaa käyttää MDiskiä eri RAID/DRAID-tasoilla samantyyppisillä levyillä. Emme mene tähän liian syvälle, koska... aiomme käsitellä tätä yhdessä seuraavista artikkeleista. Itse asiassa Pool on jaettu volyymeihin, jotka esitetään käyttämällä yhtä tai toista lohkopääsyprotokollaa isännille.
Joten me, kohdassa kuvatun tilanteen seurauksena APAR HU02104, kolmen levyn loogisen epäonnistumisen vuoksi MDisk lakkasi toimimasta, mikä puolestaan johti Poolin ja vastaavien Volumien epäonnistumiseen.
Koska nämä järjestelmät ovat varsin älykkäitä, ne voidaan liittää IBM Storage Insights -pilvipohjaiseen valvontajärjestelmään, joka lähettää automaattisesti palvelupyynnön IBM-tukeen, jos ongelma ilmenee. Sovellus luodaan ja IBM:n asiantuntijat suorittavat etädiagnostiikan ja ottavat yhteyttä järjestelmän käyttäjään.
Tämän ansiosta ongelma ratkesi melko nopeasti ja tukipalvelusta saatiin nopea suositus päivittää järjestelmämme aiemmin valittuun laiteohjelmistoon 8.2.1.9, joka oli tuolloin jo korjattu. Se vahvistaa .
Tulokset ja suosituksemme
Kuten sanonta kuuluu: "Kaikki on hyvin, mikä päättyy hyvin." Laiteohjelmiston virhe ei aiheuttanut vakavia ongelmia - palvelimet palautettiin mahdollisimman pian ja ilman tietojen menetystä. Jotkut asiakkaat joutuivat käynnistämään virtuaalikoneita uudelleen, mutta yleisesti ottaen olimme varautuneet negatiivisempiin seurauksiin, koska teemme päivittäin varmuuskopiot kaikista infrastruktuurielementeistä ja asiakaskoneista.
Olemme saaneet vahvistuksen, että jopa luotettavat järjestelmät, joiden luvattu saatavuus on 99,9999 %, vaativat huomiota ja oikea-aikaista huoltoa. Tilanteen perusteella olemme tehneet itsellemme useita johtopäätöksiä ja jakaneet suosituksemme:
-
On välttämätöntä seurata päivitysten julkaisua, tutkia julkaisutietoja mahdollisten kriittisten ongelmien korjaamiseksi ja suorittaa suunnitellut päivitykset ajoissa.
Tämä on organisatorinen ja jopa melko ilmeinen seikka, johon ei näytä olevan syytä keskittyä. Tällä "tasaisella alustalla" voit kuitenkin kompastua melko helposti. Itse asiassa juuri tämä hetki lisäsi yllä kuvatut ongelmat. Ole erittäin varovainen päivitysmääräyksiä laatiessasi ja seuraa niiden noudattamista yhtä huolellisesti. Tämä kohta liittyy enemmän "kurin" käsitteeseen.
-
On aina parempi pitää järjestelmä uusimmalla ohjelmistoversiolla. Lisäksi nykyinen ei ole se, jolla on suurempi numeerinen nimitys, vaan se, jonka julkaisupäivä on myöhempi.
Esimerkiksi IBM pitää vähintään kaksi ohjelmistojulkaisua ajan tasalla tallennusjärjestelmistään. Tätä kirjoitettaessa nämä ovat 8.2 ja 8.3. 8.2:n päivitykset ilmestyvät aikaisemmin. Samanlainen päivitys 8.3:lle julkaistaan yleensä pienellä viiveellä.
Julkaisussa 8.3 on useita toiminnallisia etuja, esimerkiksi mahdollisuus laajentaa MDiskiä (DRAID-tilassa) lisäämällä yksi tai useampi uusi levy (tämä ominaisuus on ilmestynyt versiosta 8.3.1 lähtien). Tämä on melko perustoiminto, mutta 8.2:ssa sellaista ei valitettavasti ole.
-
Jos päivittäminen ei jostain syystä ole mahdollista, IBM:n tekninen tuki suosittelee Spectrum Virtualize -ohjelmiston versioita 8.2.1.9 ja 8.3.1.0 aikaisemmille versioille (jos edellä kuvattu bugi koskee) sen esiintymisriskin vähentämiseksi. rajoittaa järjestelmän suorituskykyä poolitasolla, kuten alla olevassa kuvassa näkyy (kuva on otettu graafisen käyttöliittymän venäläistetyssä versiossa). Arvo 10000 IOPS näytetään esimerkkinä ja valitaan järjestelmäsi ominaisuuksien mukaan.
Rajoittaa IBM-tallennustehoa
-
On tarpeen laskea oikein varastointijärjestelmien kuormitus ja välttää ylikuormitusta. Voit tehdä tämän käyttämällä joko IBM sizer -työkalua (jos sinulla on pääsy siihen) tai kumppaneiden tai kolmannen osapuolen resursseja. On välttämätöntä ymmärtää varastointijärjestelmän kuormitusprofiili, koska Suorituskyky MB/s ja IOPS vaihtelee suuresti riippuen ainakin seuraavista parametreista:
-
toimintotyyppi: lue tai kirjoita,
-
toimintalohkon koko,
-
luku- ja kirjoitustoimintojen prosenttiosuus koko I/O-virrasta.
Toiminnan nopeuteen vaikuttaa myös se, miten tietolohkoja luetaan: peräkkäin tai satunnaisessa järjestyksessä. Kun suoritetaan useita tietojen käyttötoimintoja sovelluspuolella, on olemassa riippuvaisten toimintojen käsite. Tämä on myös suositeltavaa ottaa huomioon. Kaikki tämä voi auttaa näkemään koko datan käyttöjärjestelmän, tallennusjärjestelmän, palvelimien/hypervisoreiden suorituskykylaskureista sekä ymmärtämään sovellusten, DBMS-järjestelmien ja muiden levyresurssien "kuluttajien" toimintaominaisuuksia.
-
-
Ja lopuksi, varmista, että varmuuskopiot ovat ajan tasalla ja toimivat. Varmuuskopiointiaikataulu tulee määrittää yritykselle hyväksyttävien RPO-arvojen perusteella, ja varmuuskopioiden säännölliset eheystarkastukset tulee varmistaa (monilla varmuuskopiointiohjelmistojen toimittajilla on käytössä automaattinen varmennus tuotteisiinsa) hyväksyttävän RTO-arvon varmistamiseksi.
Kiitos, että luit loppuun asti.
Olemme valmiita vastaamaan kysymyksiisi ja kommentteihisi kommenteissa. Myös, jossa järjestämme säännöllisiä kampanjoita (alennuksia IaaS:stä ja lahjoituksia kampanjakoodeista jopa 100 % VPS:ssä), kirjoitamme mielenkiintoisia uutisia ja julkaisemme uusia artikkeleita Habr-blogissa.
Lähde: will.com