Új adatközponti merevlemezről álmodik a Google

Hibás prioritásokkal dolgoznak a merevlemezgyártók, amikor a nagyvállalati-adatközponti meghajtókat fejlesztik - kimondatlanul is ezt állítja a Google most nyilvánosságra hozott kívánságlistája. A cég a FAST 2016 konferenciára összeírta, hogy milyen koncepció mentén kellene a következő generációs HDD-ket fejleszteni, erre pedig iparági szabványt is létre lehetne hozni. Lássuk, hol tévednek a gyártók és mit hiányol jelenleg a Google a kínálatból!

Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.

Röviden összefoglalva: a Google számára a tökéletes diszk egy remek gigabájt/ár, illetve IOPS/gigabájt mutatóval rendelkező modell lenne. A vállalat szakemberei szerint a problémát ez utóbbi okozza: míg a gigabájt/ár mutató megfelelően növekszik, addig az IOPS/gigabájt érték fejlődése nem kielégítő és ez már kezd komoly infrastrukturális problémákat okozni.

A Google azon néhány globális cég közé tartozik, amelyek saját bőrükön érzik, hogy a felhős igényekhez képest a merevlemezek evolúciója csak vánszorog. A vállalat a YouTube-ot hozta fel példaként, ahova ma percenként 400 óra videót töltenek fel, ez pedig naponta egy újabb petabájtnyi adat eltárolásának feladatát rója az üzemeltetőkre. A Google prognózisa szerint ez a mennyiség exponenciálisan növekszik, öt évente nagyjából tízszeresére nő. A tárolási igényeket már ma is nagyon nehéz a szabványos merevlemezekkel kielégíteni, néhány év múlva pedig lehetetlenné válik ez a feladat - ez jelentett motivációt a 16 oldalas tanulmány elkészítéséhez.

Érdemes megjegyezni, hogy a Google javaslatai nagyrészt a különálló diszkek fejlesztéseire vonatkoznak, a vállalat mérnökei nyilván több szinttel feljebbről, az egész adatközpont szemszögéből tekintenek ezekre az egységekre. A cég ennek megfelelően fő jellemzőként a következőket határozta meg: másodpercenkénti I/O műveletek (IOPS), kapacitás, legnagyobb késleltetés (tail latency), biztonság, teljes bekerülési költség (TCO). Utóbbiba az adott diszk beszerzési ára és fogyasztása mellett olyan tényezők is beletartoznak, mint a fizikai helyigény, a működtetéshez szükséges számítási teljesítmény, illetve hálózati forgalom, valamint a javítási és karbantartási költségek. A legnagyobb késleltetés, azaz a tail latency is magyarázatra szorul, mely a ritkán előforduló, szokatlanul magas elérési időket, valamint azoknak a mennyiségi eloszlását mutatja meg.

A vállalat szakembereinek folyamatosan optimalizálniuk kell az összes diszket magában foglaló komplett kollekciót, ezért az alkalmazott modellekből összeálló mix időről-időre változik. Egyes diszkek kapacitásukat tekintve jobbak, míg más modellek az elérhető IOPS értékben kiemelkedőek, miközben a rendszerben található SSD és RAM is, amelyek a rétegzésben a gyorsítótár feladatát látják el. Ideális esetben erre a komplexitásra nem lenne szükség, a különböző karakterisztikájú meghajtók helyett egyetlen típus is ki tudná szolgálni a cég igényeit.

Leszámolás a floppy meghajtók hagyatékával

A tanulmány legnagyobb változtatást jelentő része a merevlemezek méretszabványáról, illetve annak esetleges megváltoztatásáról szól. A jelenleg széles körben elterjedt diszkek méretei egészen a 3,5 hüvelykes floppy meghajtókig illetve a 2,5 hüvelykes notebookos szabványig nyúlnak vissza, anno erre alapozva fektették le a még ma is használatos merevlemezek paramétereit.

A vállalat álláspontja alapján sem a 3,5, sem pedig a 2,5 hüvelykes lemezméret nem optimális az adatközponti felhasználáshoz. Míg előbbnél a gigabájt/ár mutató a kedvezőbb, addig utóbbival az IOPS/gigabájt érték jobb. A lemezek forgási sebességével is hasonló a helyzet, az alacsonyabb percenkénti fordulat a gigabájt/ár mutatóra van kedvező hatással, miközben az IOPS/gigabájt ezzel párhuzamosan csökken. A lemezméretre nem tett konkrét javaslatot a Google, ugyanakkor a leírtak alapján a vállalat valószínűleg egy a 3,5 és 2,5 hüvelyk közötti aranyközéputat tarthat optimálisnak, amely elérési időben és fordulatszámban is kompromisszumot jelentene.

A tanulmány nem csak a lemezmérettel nincs megelégedve, a Google szerint a meghajtók maximális magassága sem ideális. A 3,5 hüvelykes szabvány esetében ez az érték 2,54 centiméterben (1 hüvelyk), a 2,5 hüvelykes szabványnál pedig 1,5 centiméterben tetőzik. Az értéket jelentősen megnövelve adott meghajtóba több lemez férhetne, miközben bizonyos komponensek (motor, elektronika) száma változatlan maradna, ami kedvezően hatna gigabájt/ár mutatóra.

Egy fej már kevés

Az IOPS értékek növeléséért a Google mérnökei a fejek elrendezéséhez is hozzányúlnának, amire több ötlet is felvázol a tanulmány. Az elsővel a lemezoldalankénti fejek számát dupláznák, úgy, hogy a meghajtóba egy másik, motort, karokat, illetve fejeket tartalmazó blokkot építenének az ellenkező oldalra. Ez a megoldás igen költséges lenne, ugyanakkor gyakorlatilag az összes művelettípus teljesítményét duplázná. Az ötlet nem új keletű, a 90-es évek környékén a Conner "Chinook" már alkalmazott hasonló megoldást.

Egy másik, olcsóbb variáció a jelenlegi megoldást egészítené ki, egyetlen karra két fejet pakolna, az első egység a szokásos pozícióban a kar végén, a másik pedig középtájon helyezkedne el. Ezzel relatíve egyszerűen kivitelezhető, ugyanakkor csak a szekvenciális műveletek sebessége gyorsulna. Ehhez hasonló a felvetés, miszerint olyan fej kerülne a kar végére, mely egy időben két szomszédos sávot képes olvasni és írni, amivel ismételten csak a szekvenciális műveletek gyorsulnának, ami a Google számára csupán másodlagos az IOPS mögött.

Az SMR önmagában nem az igazi

A tanulmány a manapság egyre népszerűbb SMR (Shingled Magnetic Recording) szektorrendezési technológiára is kitér. Az átlapolást alkalmazó megoldással jelenleg nagyjából 20-25 százalékkal növelhető a lemezek adatsűrűsége, viszont cserébe átviteli sebesség olykor jelentősen csökken, ergo ez a megoldás a gigabájt/ár mutatót növeli az IOPS/gigabájt kárára. Ennek okán az SMR-t alkalmazó merevlemezekre csak úgynevezett hideg adatot helyeznek, melynek hozzáférése kiszámítható, megjósolható.

A Google ugyanakkor kihasználná az SMR-t, mégpedig egy hibrid meghajtó keretein belül, melyben a konvencionális CMR mellett SMR lemezek is találhatóak, amivel a gigabájt/ár és a IOPS/gigabájt mutatót egyaránt növelni lehetne. Ebben az esetben a CMR lemezekről idővel az SMR lemezekre lehetne átmozgatni olyan adatokat, amiket a rendszer végül hosszú élettartamúnak jelöl, így meghajtón belül jönne létre rétegzés.

A Google akár még ennél is tovább menne, a tanulmány szerint a fixen kombinált lemezeknél hosszabb távon optimálisabb lenne, ha adott lemezen belül rugalmasan lehetne kombinálni a hagyományos CMR, illetve a nagyobb adatsűrűséget kínáló SMR sávokat. Így a lemez külső részére CMR, míg a belsőre SMR sávok kerülhetnének. Ezzel az SMR által kínált extra kapacitás kisebb lenne, ugyanakkor a CMR sávok kompenzálni tudnák az IOPS csökkenését.

Még nagyobb szektorok

A Google a szektorok méretét is növelné. Ehhez legutóbb az előző évtized végén nyúlt az ipar, ekkor a nagyjából 23 évig alkalmazott 512 bájtos szektorokat 4096 bájtra, vagyis 4 kilobájtra emelték. Ezzel egységnyi kapacitás mellett csökkenteni lehetett a minden egyes adatszektorhoz tartozó külön vezérlőblokkok (Synchronization Pattern/Data Address Mark, Sync/DAM) és hibajavító (ECC) blokkok számát, mellyel értékes lemezterületet lehetett megtakarítani.

A tárolók esetében ugyanakkor ez is kevés, hisz ezek a rendszerek jellemzően saját fájlrendszerrel dolgoznak, a kiírt adatok pedig egyben CRC hibajavítást is tartalmaznak. Ezért a Google 64 kilobájtos vagy akár nagyobb szektorokat javasol, amivel tovább lehetne növelni a hasznos tárterületet.

Okosabb és biztonságosabb firmware

A dokumentum a firmware kérdésére is kitért. Itt a Google elsősorban nagyobb biztonságot szeretne, hisz nem is oly rég robbant ki egy ezzel kapcsolatos botrány, amikor is a támadók közvetlen hozzáférést tudtak szerezni a merevlemezek (illetve SSD-k) firmware-éhez, egy API-n keresztül pedig bizonyos rejtett szektorokra tudtak írni. Ezzel a módszerrel a malware-ek gyakorlatilag kiirthatatlanok lettek, és egy szinte tökéletesen álcázott tárhelyen gyűjthették az információt.

A Google könnyebben ellenőrizhető, illetve nehezebben módosítható firmware-eket szeretne, amiket különféle, más rendszereknél már alkalmazott biztonsági technológiákkal egészítenének ki. A vállalat az ilyesfajta támadások ellen jelenleg a lemezek megfelelő elzárásával, illetve a gazda operációs rendszer és a meghajtók közötti egyfajta izolációval védekezik, hogy a rendszer biztosan ne tudja módosítani a firmware-t.

A biztonság növelése mellett ugyanakkor nyitottabb analitikát, illetve profilozhatóságot is szeretne a vállalat. Az egyes diszkek működésének folyamatos és részletes nyomon követése további optimalizációk előtt nyitna utat. A tanulmány ezzel kapcsolatban olyan paramétereket emel ki mint a fejmozgással (seek) eltöltött, egységnyi adat továbbításához, illetve a hibajavításhoz szükséges idő. Ezen felül a különféle műveletek számának mérése is hasznos lehet, ily módon látható lenne, hogy hány darabot kezdeményezett a rendszer, illetve maga a meghajtó, mondjuk valamilyen önkarbantartás miatt.

Még akár a megbízhatóság árán is

A Google kitér a megbízhatóság kérdésére is, mely alapján a vállalat hajlandó lenne lejjebb adni a jelenlegi igényekből. A tanulmány ezt a magasabb szintű redundanciával magyarázza, amit még abban az esetben is biztosan alkalmaznának, ha az egyes diszkek tökéletesek lennének, ergo a meghibásodás esélye zéró lenne. Annak fényében tehát, hogy az adott lemezen található adat a meghajtó részleges vagy teljes meghibásodása esetében is biztosan elérhető marad, a Google a kapacitás növelése vagy a legnagyobb késleltetés csökkentése érdekében engedne a sztenderdnek számító BER (Bit Error Rate) értékből, mely jelenleg 10¹⁵-t jelent.

Miért nem csak SSD?

Bár az egyes szempontok között a kapacitás mellett kiemelkedő helyen szerepel az IOPS érték, az SSD-k relatíve magas áruk, pontosabban kedvezőtlen ár/gigabájt mutatójuk miatt továbbra sem jelentenek alternatívát a naponta létrejövő újabb petabájtos méretű adathalmaz eltárolásához. Ezen felül a Google álláspontja szerint az igényeiknek megfelelő vállalati SSD-k és a merevlemezek kapacitása jelenleg nagyjából hasonló ütemben növekszik, így a helyzet az elkövetkező jó néhány évben nem fog számottevően változni.

A Google reményei szerint most megjelent tanulmány megadja az alaphangot egy nagyobb méretű ipari egyeztetéshez, mellyel végre megkezdődhet a jövő adatközpontos merevlemezeinek fejlesztése. A vállalat kiemeli, hogy egy egységes szabványban látja a jövőt, aminek megalkotásában a gyártók mellett a konkurensek közreműködésére is számít.