Ma mesélni fogok Önöknek egy történetet. A számítástechnika evolúciójának és a távoli munkahelyek megjelenésének történetéről az ókortól napjainkig.
Az IT fejlődése
A legfontosabb dolog, amit az IT történetéből tanulhatunk — az az...
Természetesen az IT spirális fejlődése. Ugyanazokat a megoldásokat és koncepciókat, amelyeket évtizedekkel ezelőtt elvetettek, új értelmet nyernek és sikeresen kezdenek el működni új körülmények között, új feladatokkal és új teljesítménnyel. Ebben az IT semmiben sem különbözik az emberi tudás bármely más területétől és a Föld történelmétől összességében.
Réges-régen, amikor a számítógépek hatalmasak voltak
„Azt hiszem, a világon körülbelül öt számítógép piacának van helye” — mondta Thomas Watson, az IBM vezetője 1943-ban.
A korai számítástechnika nagy volt. Nem, ez nem igaz, a korai eszközök szörnyűek és óriásiak voltak. Egy teljes számítógép olyan területet foglalt el, mint egy sportcsarnok, és elképzelhetetlenül drága volt. Példaként említhetjük a ferritgyűrűs memória modulokat (1964).
Ez a modul 11 cm * 11 cm-es, és 512 byte (4096 bit) kapacitással rendelkezik. Egy szekrény, tele ezekkel a modulokkal, alig érte el a régi, ma már ismerős 3,5” floppy lemez kapacitását (1,44 MB = 2950 modul), ugyanakkor jelentős mennyiségű elektromos energiát fogyasztott, és olyan forró volt, mint egy gőzmozdony.
Éppen a hatalmas méretek miatt lett angolul a programkód hibakeresésének neve az egyszerűsített „debugging”. A történet egyik első programozója, Grace Hopper (igen, nő) a haditengerészet tisztje 1945-ben bejegyzést tett a naplójába a program hibájának kivizsgálása után.
Mivel a moth (moth) általában bug (rovar), minden további probléma és annak megoldása a személyzet által „debugging”-nak (szó szerint: rovarmentesítés) számított, a programhiba és a kódhiba elnevezése végleg a bug-ra ragadt, míg a hibakeresés a debug lett.
Ahogy az elektronika és különösen a félvezető elektronika fejlődött, a gépek fizikai méretei csökkentek, míg a számítási teljesítmény nőtt. De még így sem lehetett mindenkinek egyéni számítógépet adni.
„Nincs ok arra, hogy valaki a számítógépét otthon tartsa” — Ken Olsen, a DEC alapítója, 1977.
A 70-es években jelenik meg a mini-számítógép kifejezés. Emlékszem, amikor sok évvel ezelőtt először olvastam erről a kifejezésről, úgy képzeltem, hogy valami netbook-szerű dolog, gyakorlatilag egy zsebszámítógép. Ennél távolabb nem is lehettem volna az igazságtól.
A mini — csak a hatalmas géptermekhez képest, de ez még mindig több szekrénynyi berendezés, amelynek ára százezrek és milliók dollárra rúg. Azonban a számítási teljesítmény már annyira megnőtt, hogy nem mindig volt 100%-ban kihasználva, és ezenfelül a számítógépek hozzáférhetővé váltak egyetemista diákok és oktatók számára is.
És ekkor megérkezett Ő!
Kevesen gondolkodnak az angol nyelv latin eredetén, de ő hozta el számunkra a távoli hozzáférést, ahogy ma tudjuk. Terminus (latin) — vég, határ, cél. A T800 Terminátor célja John Connor életének vége. Ahogy azt is tudjuk, hogy azok az állomások, ahol az utasok beszállnak és kiszállnak, vagy ahol a rakományt fel- és lerakják, termináloknak hívják — útvonalak végső céljait.
Így megjelent a terminális hozzáférés fogalma, és láthatja a világ legismertebb terminálját, amely továbbra is él szívünkben.
A DEC VT100 terminálnak hívják, mivel lezárja az információs vonalat. Gyakorlatilag nulla számítási teljesítménye van, és egyetlen feladata az, hogy megjelenítse a nagy géptől kapott információt, és átadja a nagy gépnek a billentyűzetről érkező bemenetet. Bár a VT100 fizikailag régóta „meghalt”, mi még mindig teljes mértékben használjuk őket.
Mai napjaink
A “mai napjainkat” az 1980-as évek elejétől számítanám, amikor megjelentek az első, széles körben hozzáférhető processzorok, amelyek valamennyire jelentős számítási teljesítménnyel bírtak. Hagyományosan úgy tartják, hogy a korszak fő processzora az Intel 8088 (x86 család) lett, mint a győztes architektúra ősatyja. Mi tehát a lényegi különbség a 70-es évek koncepciójához képest?
Először jelenik meg a tendencia, hogy az információfeldolgozást a központból a perifériára helyezik át. Messze nem minden feladat igényel olyan elképesztő (a gyenge x86-hoz képest) mainframe teljesítményt, vagy akár egy mini számítógépet. Az Intel nem áll meg, az 1990-es években kiadja a Pentium családot, amely valóban az első tömeges otthoni processzor lett Oroszországban. Ezek a processzorok már sokra képesek, nemcsak levelet írni — hanem multimédiát kezelni és kis adatbázisokkal dolgozni is. Gyakorlatilag a kisvállalkozások számára teljesen feleslegessé válik a szerverek használata — minden elvégezhető a periférián, az ügyfélgépeken. Évről évre a processzorok egyre nagyobb teljesítményűek, és a szerverek valamint a személyi számítógépek közötti különbség egyre csökken a számítási teljesítmény szempontjából, gyakran csak az áramellátás fenntartásában, a forró csere támogatásában és a rackbe való beépítésre szolgáló különleges házakban maradva.
Ha összehasonlítjuk a modern ügyfélaruházati processzorokat az 1990-es évek Intel cég „vicces” nehéz szervereihez hasonlítva a múlt szuperszámítógépeivel, az már egy kicsit kellemetlen érzést kelt.
Nézzük meg a régi barátot, amely gyakorlatilag az én korosztályom. Cray X-MP/24, 1984-ből.
Ez a gép a 1984-es szuperszámítógépek legjobbjai közé tartozott, 2 db, 105 MHz-es processzorral, a csúcsteljesítménye 400 MFlops (millió lebegő pontos művelet). Az a gép, amely a képen látható, az Egyesült Államok Nemzetbiztonsági Ügynöksége titkos laboratóriumában állt, és titkosírások feltörésével foglalkozott. Ha átszámítunk 15 millió dollárt 1984-ből 2020-ra, akkor az értéke kb. 37,4 millió dollár, vagyis 93 500 dollár / MFlops.
Abban a gépben, amin írom ezeket a sorokat, egy Core i5-7400 processzor található, 2017-ből, ami egészen nem új, és még a megjelenésének évében is a legfiatalabb 4 magos processzor volt a középkategóriás asztali processzorok között. 4 mag 3.0 GHz alapfrekvenciával (3.5 Turbo Boost-tal), és a HyperThreading által biztosított dupla szálak 19 és 47 GFlops közötti teljesítményt nyújtanak különböző tesztjeim során, miközben ára 16 ezer rubel a processzorért. Ha egy gépet összerakunk teljesen, annak költségét kb. 750 dollárra becsülhetjük (a 2020. március 1-i árak és árfolyamok szerint).
Végül elmondhatjuk, hogy a korunk átlagos asztali processzora 50-120-szoros előnyben van a múlt egyértelműen legjobbjai közé tartozó szuperszámítógépek felett, míg a MFlops egységárának csökkenése egészen elképesztően 93500 / 25 = 3700-szoros.
Miért van még szükségünk szerverekre és a számítások központosítására, amikor ilyen erőforrások állnak rendelkezésre a peremhálózon - ez határozottan nem világos!
Visszafelé ugrás - a spirál megfordult
Lemez nélküli munkállomások
Az első jel, hogy a számítások perifériára helyezése nem lesz végleges, a lemez nélküli munkállomás technológia megjelenése volt. A munkaállomások jelentős eloszlása a vállalaton belül, különösen szennyezett helyiségekben, nagyon éles kérdéseket vet fel a munkállomások kezelésével és támogatásával kapcsolatban.
Megjelenik a „folyosóidő” fogalma - az a százalékos idő, amit a műszaki támogatási munkatárs tölt a folyosón, az ügyfél felé haladva, aki problémával keresett meg. Ez az idő fizetett, de teljesen terméketlen. Különösen szennyezett helyiségekben a merevlemezek meghibásodása játszotta a legnagyobb szerepet. Töröljük el a munkállomásból a meghajtót, és mindent végezzünk a hálózaton, beleértve a betöltést is. A hálózati adapter DHCP-szervertől kapja meg a címet, valamint további információt - a TFTP-szerver címét (egyszerűsített fájl szolgáltatás) és a betöltendő kép nevét, letölti azt a rendszermemóriába, és elindítja a gépet.
A kevesebb meghibásodás és a folyosóidő csökkentése mellett a gépet most már nem szükséges a helyszínen beállítani, egyszerűen csak új gépet hozhatunk és elvihetjük a régit egy diagnosztikai berendezett munkahelyre. De ez még nem minden!
A lemez nélküli munkállomás jelentősen biztonságosabbá válik - ha valaki betör a helyiségbe és elvisz minden számítógépet, az csak a berendezés elvesztését jelenti. Nincs adat tárolva a lemez nélküli munkállomásokon.
Ezt a pillanatot ne felejtsük el, az információbiztonság egyre fontosabb szerepet játszik az információs technológiák „bajmentes gyermekkora” után. Az IT világába egyre inkább hármas, félelmetes és fontos betűk betörnek - GRC (Governance, Risk, Compliance), vagyis magyarul: 'Irányítás, Kockázat, Megfelelőség'.
Terminál szerverek
A személyi számítógépek egyre nagyobb elterjedése a perifériákon jelentősen megelőzte a nyilvános hálózatok fejlődését. A klasszikus, 90-es évek közepén és 2000-es évek elején elterjedt kliens-szerver alkalmazások nem működtek jól vékony csatornákon, különösen akkor, ha az adatmennyiség bármennyire is jelentős volt. Különösen nehéz helyzetben voltak a távoli irodák, amelyek modem segítségével csatlakoztak, telefonvonali kapcsolaton, amely amúgy is gyakran akadozott vagy megszakadt. És...
A spirál újra körbeért, és visszatért a terminál üzemmódba a terminál szerverek koncepciójával.
Valójában visszatértünk a 70-es évekhez a nulla kliensekkel és a számítási teljesítmény centralizálásával. Nagyon gyorsan nyilvánvalóvá vált, hogy a tisztán gazdasági szempontok mellett a terminális hozzáférés hatalmas lehetőségeket kínál a biztonságos külső hozzáférés megszervezésére, beleértve a otthoni munkavégzést a munkavállalók számára, vagy a rendkívül korlátozott és kontrollált hozzáférést a szerződött munkavállalók számára megbízhatatlan hálózatokból és ellenőrizetlen eszközökről.
Mindazonáltal a terminál szerverek, minden előnyükkel és haladóságukkal együtt, számos hátránnyal is rendelkeztek - alacsony rugalmasság, szomszéd zajproblémája, szigorúan serveroldali Windows, stb.
A proto VDI megszületése.
Igaz, hogy a 2000-es évek elejéig tágabb láthatáron megjelent az ipari virtualizáció az x86 platformon. Valaki pedig csak úgy kimondta a levegőben lebegő ötletet: mi lenne, ha ahelyett, hogy minden klienst centralizálnánk a szerver alapú terminálfarmokon, mindenkinek adnánk egy saját virtuális gépet kliens Windows-szal és adminisztrátori hozzáféréssel?
A vastag kliensekről való lemondás.
Párhuzamosan a munkamenetek és az operációs rendszerek virtualizációjával az alkalmazás szintjén a kliens funkció leegyszerűsítésével kapcsolatos megközelítés fejlődött.
A logika ennél viszonylag egyszerű volt, hiszen a személyi laptopok még messze nem mindenkinél voltak, az internet szintén nem volt mindenkinél elérhető, és sokan csak internet kávézókból tudtak csatlakozni, nagyon korlátozott jogokkal. Valójában mindössze annyit tudtak futtatni, hogy a böngésző. A böngésző kötelező attribútummá vált az operációs rendszer számára, az internet pedig szervesen beépült az életünkbe.
Más szavakkal, párhuzamosan terjedt az a trend is, hogy a logikát a kliensről a központba helyezzük webalkalmazások formájában, amelyekhez csak a legbasicbb kliens, internet és böngésző szükséges.
És nem csupán ott tartottunk, ahol kezdtük – nullás ügyfelek és központi szerverek mellett. Több független úton érkeztünk oda.
Virtuális Asztali Infrastruktúra
Brokker
2007-ben a piacon vezető ipari virtualizációs vállalat, a VMware kiadta első VDM (Virtuális Asztali Menedzser) termékének verzióját, amely gyakorlatilag az első volt a még csak fejlődő virtuális asztalok piacán. Természetesen nem kellett sokat várni a terminálszerverek vezetőjének, a Citrix-nek a válaszára sem, és 2008-ban a XenSource felvásárlásával megjelent a XenDesktop. Nyilvánvaló, hogy voltak más szállítók is saját ajánlataikkal, de ne térjünk el túlzottan a történettől, elkerülve a koncepciótól való eltérést.
A koncepció továbbra is fennáll. A VDI kulcsfontosságú összetevője a kapcsolatokat kezelő bróker.
Ez a virtuális asztali infrastruktúra szíve.
A bróker felelős a VDI legfontosabb működési folyamataiért:
- Meghatározza az ügyfél számára elérhető kimenő erőforrásokat (gépek/szekciók);
- Szükség esetén a klienseket géppoolokra/szekciókra osztja;
- Átirányítja az ügyfelet a kiválasztott erőforrásra.
Ma a VDI ügyfele (terminál) gyakorlatilag bármi lehet, ami rendelkezik kijelzővel – laptop, okostelefon, tablet, kiosk, vékony vagy nullás kliens. Az az elem, amely végrehajtja a produktív terhelést – terminálszerver szekció, fizikai gép, virtuális gép. A modern érett VDI termékek szorosan integrálódnak a virtuális infrastruktúrával, és önállóan, automatikusan kezelik azt, telepítve vagy éppen ellenkezőleg, eltávolítva a már nem szükséges virtuális gépeket.
Bár kissé különállóan, de egyes ügyfelek számára a VDI körében rendkívül fontos technológia a 3D grafika hardveres gyorsításának támogatása, amely szükséges tervezők vagy dizájnerek munkájához.
Protokoll
A második rendkívül fontos része a fejlett VDI megoldásnak a virtuális erőforrásokhoz való hozzáférési protokoll. Ha a vállalati belső hálózaton belüli munkáról van szó, kiváló megbízható 1 Gbps sebességgel az munkahely felé és 1 ms késleltetéssel, akkor gyakorlatilag bármelyiket választhatjuk, és egyáltalán nem kell gondolkodnunk.
Gondolkodni kell, amikor a kapcsolat ellenőrizetlen hálózaton keresztül jön létre, a hálózat minősége pedig bármilyen, akár tíz kilobit sebességig és kiszámíthatatlan késleltetésekig terjedhet. Ezek pont azok, amik a valódi távoli munkavégzéshez szükségesek, nyaralókban, otthon, repülőtereken és gyorséttermekben.
Terminál szerverek vs kliens VM-ek
A VDI megjelenésével úgy tűnt, hogy ideje búcsút mondani a terminál szervereknek. Miért van szükség rájuk, ha mindenkinek megvan a saját személyes VM-je?
Azonban tiszta gazdasági szempontból kiderült, hogy a tipikus, unalmasan azonos munkahelyek esetében eleddig nem létezik hatékonyabb megoldás a terminál szervereknél az ár/session arány szempontjából. Minden előnyük ellenére a „1 felhasználó = 1 VM” megközelítés jelentősen nagyobb erőforrást igényel a virtuális hardverhez és a teljes operációs rendszerhez, ami rombolja a gazdaságosságot a tipikus munkahelyeken.
A top menedzserek munkahelyeivel, nem szabványos és terhelt munkahelyeivel, és a magas jogosultságok (akár adminisztrátori szintűek) szükségességével a dedikált VM felhasználónként előnyösebb. Ezen a VM-en belül egyénileg lehet erőforrásokat allokálni, bármilyen szintű jogosultságokat adni, és a VM-eket kiegyensúlyozni a virtualizáló hosztok között magas terheltség esetén.
VDI és gazdaság
Évek óta hallom ugyanazt a kérdést — de hogyan, a VDI olcsóbb, mint egyszerűen adni mindenkinek egy laptopot? És évek óta ugyanazt a választ kell adnom: a normál irodai dolgozók esetében a VDI nem olcsóbb, ha a berendezés fenntartási költségeit nézzük. Akárhogy is, a laptopok olcsóbbá válnak, míg a szerverek, tárolórendszerek és rendszerszoftverek meglehetősen jelentős összegekért kaphatók. Ha itt az ideje frissíteni a flottát, és spórolni szeretne a VDI-vel — nem fog spórolni.
Előzőleg említettem a borzalmas három betűt, a GRC-t — nos, a VDI a GRC-ről szól. Ez a kockázatkezelésről szól, a biztonságról és az adatokhoz való szabályozott hozzáférés kényelméről. És ez általában meglehetősen jelentős költségekkel jár, ha sokféle gépen valósítják meg. A VDI segítségével a kontroll egyszerűsödik, a biztonság növekszik, és a hajak lágyak és selymesek lesznek.
HPE megoldások távoli munkavégzéshez
Távoli és felhőalapú irányítás
iLO
Az HPE cég nem új a távoli szerverinfrastruktúra kezelés terén; áprilisban ünnepelhettük a legendás iLO (Integrated Lights Out) 18. születésnapját. Emlékezve a rendszergazdai időimre a 2000-es években, alig tudtam betelni vele. Az első telepítést a rackekbe és a kábelek csatlakoztatását kellett csak elvégezni a zajos és hideg adatközpontban. Minden más konfigurálását, beleértve az operációs rendszer telepítését is, már a munkahelyemről, két monitorral és egy csésze forró kávéval lehetett intézni. Ez 13 évvel ezelőtt történt!
Manapság az HPE szerverek nem véletlenül számítanak évtizedek óta a minőség megkérdőjelezhetetlen standardjának — ebben pedig jelentős szerepet játszik a távoli kezelés arany standardja, az iLO.
Külön meg kell említeni az HPE lépéseit az emberi ellenőrzés fenntartásában a koronavírus felett. , hogy 2020 végéig (minimum) az iLO Advanced licensz mindenki számára ingyenesen elérhető.
Infosight
Ha több mint 10 szerver van az infrastruktúrában, és az adminisztrátor nem szenved unalomban, akkor természetesen kiváló kiegészítése a standard monitorozó eszközöknek a felhőalapú HPE Infosight rendszer, amely mesterséges intelligencián alapul. A rendszer nemcsak figyeli az állapotot és grafikont készít, hanem önállóan javasolja a következő lépéseket a jelenlegi helyzet és trendek alapján.
Legyél okos, , próbáld ki az Infosightot!
OneView
Utolsóként, de nem a jelentősége szerint, szeretném megemlíteni az HPE OneView-t — egy teljes termékportfólió hatalmas monitorozási és kezelési lehetőségekkel az egész infrastruktúra számára. Mindemellett mindezt anélkül, hogy fel kellene állnod az íróasztalodtól, amely talán jelenleg egyszerűen a nyaralódban található.
A tárolóeszközök sem nyuszik!
Természetesen az összes tárolóeszköz távolról kezelhető és monitorozható — ez már évekkel ezelőtt is így volt. Ezért ma egy másik témáról szeretnék beszélni, nevezetesen a metró klaszterekről.
A metró klaszterek nem új találmány a piacon, de éppen ezért nem túl népszerűek — a gondolkodás inerciajai és az első benyomások nyomot hagynak. Persze, 10 évvel ezelőtt már léteztek, de annyiba kerültek, mint egy vaskos híd. Az azóta eltelt évek megváltoztatták az ipart és a technológia hozzáférhetőségét a nagyközönség számára.
Emlékszem olyan projektekre, ahol szándékosan elkülönítették a tárolórendszer részeit - külön a szuperkritikus szolgáltatásoknak a metroklaszterben, külön a szinkron replikációhoz (sokkal olcsóbb).
Valójában, 2020-ban a metroklaszter semmibe sem kerül, ha képes vagy két helyszínt és kommunikációs csatornákat szervezni. A szinkron replikációhoz szükséges csatornák pontosan ugyanazok, mint a metroklaszterekhez. A szoftverlicenszek már régóta csomagokban jönnek - és a szinkron replikáció azonnal csomagban érkezik a metroklaszterrel, és az egyetlen dolog, ami jelenleg életben tartja az egyirányú replikációt - az a kiterjedt L2 hálózat megszervezésének szükségessége. Még úgy is, hogy az L2 over L3 már országszerte terjed.
Mi a lényegi különbség a szinkron replikáció és a metroklaszter között a távoli munka szempontjából?
Minden nagyon egyszerű. A metroklaszter automatikusan, mindig, gyakorlatilag azonnal működik.
Hogyan néz ki a terhelés átvitele a szinkron replikációnál legalább több száz VM infrastruktúráján?
- Jelzés érkezik a hibáról.
- A ügyeletes műszak elemzi a helyzetet - nyugodtan számolhatsz 10-30 perccel csak a jelzés fogadásához és a döntés meghozatalához.
- Ha az ügyeletes mérnököknek nincs felhatalmazásuk az átkapcsolás önálló indítására - akkor még 30 percet számolhatsz a kapcsolattartásra az illetékes személlyel és a váltás hivatalos megerősítésére.
- A Nagy Piros Gomb megnyomása.
- 10-15 perc a timeoutokra és a kötetek újratervezésére, a VM-ek újraregisztrálására.
- 30 perc az IP-cím módosítására - optimista becslés.
- Végül a VM-ek indítása és a termelési szolgáltatások elindítása.
Összességében az RTO (az üzleti folyamatok helyreállítási ideje) nyugodtan 4 órára becsülhető.
Hasonlítsuk össze a metroklaszter helyzetével.
- A tárolórendszer érzékeli, hogy a metroklaszterrel a kapcsolat megszakadt - 15-30 másodperc.
- A virtualizáló hosztok érzékeli, hogy az első adatközpont elveszett - 15-30 másodperc (egyszerre az 1. ponttal).
- Automatikus újraindítás fél és egyharmad közötti VM számra a második adatközpontban - 10-15 perc a szolgáltatások betöltéséhez.
- Körülbelül ekkor a ügyeletes műszak már érti, hogy mi történt.
Összességében: RTO = 0 egyes szolgáltatások esetén, 10-15 perc általános esetben.
Miért csak a VM-ek fél és egyharmada indul újra? Nézd meg, miről van szó:
- Mivel Önök mindent okosan csinálnak, és bekapcsolják a virtuális gépek automatikus terheléselosztását. Ennek eredményeként átlagosan csak a virtuális gépek fele fut az egyik adatközpontban. Végtére is a metroklaszter minden lényege a leállások minimalizálása, így érdekükben áll minimalizálni a veszélyben lévő virtuális gépek számát.
- Egyes szolgáltatásokat lehet klaszterezni az alkalmazás szintjén, különböző virtuális gépekre osztva őket. Így ezek a párba állított virtuális gépek vagy szögekkel be vannak rögzítve, vagy szalaggal vannak rögzítve különböző adatközpontokhoz, hogy a szolgáltatás ne várakozzon a virtuális gép újraindítására baleset esetén.
Jól felépített infrastruktúrával és elnyújtott metroklaszterekkel a vállalati felhasználók minimális késleltetéssel dolgoznak bármilyen pontból, még adatközpont szintű baleset esetén is. A legrosszabb esetben a késleltetés egy csésze kávé idejét teszi ki.
És természetesen a metroklaszterek kiválóan működnek mind a Valinor felé mozgó HPE 3Par-on, mind az új Primera platformokon!
Távoli munkahelyek infrastruktúrája
Terminál szerverek
Terminális szerverekhez nem szükséges újat kitalálni, évek óta a HPE a világ egyik legjobb szervereit szállítja a számukra. Az időtlen klasszikusok — DL360 (1U) vagy DL380 (2U), vagy AMD kedvelőknek — DL385. Természetesen vannak blade szerverek is, mint a klasszikus C7000, valamint az új, összeállítható Synergy platform.
Minden ízlésnek, minden színben, maximális munkamenetek a szerveren!
„Klasszikus” VDI + HPE Simplivity
Ebben az esetben, amikor „klasszikus VDI”-ról beszélek, az 1 felhasználó = 1 virtuális gép kliens Windows koncepcióját értem. És természetesen nincs közelebb és ismerősebb VDI terhelés a hiper-összevonó rendszerekhez, főleg deduplikációval és tömörítéssel.
Itt az HPE saját hiper-összevonó platformját, a Simplivity-t, valamint partnerek megoldásaihoz tanúsított szervereket / csomópontokat kínálhat, például VSAN Ready Nodes-t a VDI VMware VSAN infrastruktúrájára alapozva.
Beszéljünk egy kicsit bővebben a saját Simplivity megoldásunkról. A név, ahogy finoman utal, a egyszerűség (angolul simple — egyszerű) áll a középpontban. Az elrendezés egyszerűsége, a kezelés egyszerűsége, a skálázás egyszerűsége.
A hiperkonvergens rendszerek ma az IT egyik legforróbb témája, és a különböző szintű gyártók száma körülbelül 40. A Gartner varázskockája szerint az HPE a globális Top 5-ben van, és a vezetők négyzetében helyezkedik el — ezek azok, akik értik, hová fejlődik az ipar, és képesek ezt a megértést megvalósítani hardver formájában.
Az architektúra a Simplivity esetében klasszikus hiperkonvergens rendszer, vezérlő virtuális gépekkel, ami lehetővé teszi különböző hipervizorok támogatását, ellentétben a hipervizorba integrált rendszerekkel. Valóban, 2020 áprilisi állapot szerint támogatott a VMware vSphere és a Microsoft Hyper-V, és tervezik a KVM támogatását is. A Simplivity egyik kulcsa, amióta a piacon van, a speciális gyorsítókártyával végzett hardveres tömörítés és deduplikáció.
Meg kell jegyezni, hogy a tömörítés és deduplikáció globálisan és folyamatosan be van kapcsolva, tehát ez nem egy opcionális jellemző, hanem a megoldás architektúrája.
Az HPE persze némileg túloz, amikor 100:1 hatékonyságról beszél, mivel különös módon számolja ki, de a térhasználat hatékonysága valóban nagyon magas. Csak a 100:1 szám túl szép ahhoz, hogy igaz legyen. Tekintsük át, hogyan valósult meg technikailag a Simplivity, hogy ilyen számokat tudjon mutatni.
Snapshot. A pillanatfelvételek (snapshotok) 100%-ig helyesen, RoW (Redirect-on-Write) módon valósultak meg, tehát azonnal történnek, és nem járnak teljesítménycsökkenéssel. Ezzel például eltérnek más rendszerektől. Miért van szükségünk lokális snapshotokra a büntetések nélkül? Nagyon egyszerű, hogy csökkentsük az RPO-t 24 óráról (az átlagos RPO a biztonsági mentéshez) percekre vagy akár egy pár percre.
Backup. A snapshot a biztonsági mentéstől csak abban különbözik, ahogyan azt a virtuális gépek kezelő rendszere érzékeli. Ha egy gép törlésekor minden más is törlődik — akkor az egy snapshot volt. Ha maradt valami — akkor az egy biztonsági másolat (backup). Így bármely snapshot teljes biztonsági másolatnak is tekinthető, ha azt a rendszerben megjelölik és nem törlik.
Természetesen sokan ellentmondanának – milyen biztonsági mentés az, ha ugyanazon a rendszeren tárolják? Itt van egy nagyon egyszerű válasz egy visszautasító kérdés formájában: van formalizált fenyegetésmodelljük, ami meghatározza a biztonsági másolatok tárolásának szabályait? Ez egy teljesen korrekt biztonsági mentés a fájl törlésével szemben a virtuális gépen, ez a biztonsági mentés a virtuális gép törlésével szemben. Ha viszont az a szükség, hogy a biztonsági másolat kizárólag egy elválasztott rendszeren legyen tárolva, van választási lehetőség: az adott pillanatfelvétel replikálása a második Simplivity klaszterre vagy a HPE StoreOnce-ra.
És pontosan itt jön rá, hogy ez az architektúra egyszerűen tökéletesen megfelel bármilyen VDI típusnak. A VDI ugyanis több száz, akár ezer nagyon hasonló gépet jelent, mind ugyanazzal az operációs rendszerrel és azonos alkalmazásokkal. A globális deduplikáció mindezt fel fogja dolgozni és tömöríteni még nem 100:1 arányban, hanem annál sokkal jobban. 1000 virtuális gép telepítése egyetlen sablonból? Egyáltalán nem probléma, ezek a gépek hosszabb ideig fognak megjelenni a vCenterben, mint ameddig klónozni lehet őket.
Kifejezetten a különleges teljesítményigényű felhasználók számára, és azok számára, akiknek 3D gyorsítókra van szükségük, készült a Simplivity G sorozat.
Ebben a sorozatban nem használnak hardveres deduplikáló gyorsítót, ezért csökkentették a diszkek számát csomópontonként, hogy a vezérlő programozott módon tudja kezelni. Ennek köszönhetően szabad PCIe slotok maradnak más gyorsítók számára. Továbbá a rendelkezésre álló memória mennyisége 3TB-ra nőtt csomópontonként a legigényesebb terhelésekhez.
A Simplivity ideálisan alkalmas földrajzilag elosztott VDI infrastruktúrák létrehozására, adatmásolással a központi adatközpontba.
Ez a VDI architektúra (és nem csak a VDI) különösen izgalmas a orosz viszonyok között - hatalmas távolságok (és következésképpen késések) és nem éppen ideális csatornák mellett. Regionális központok jönnek létre (vagy akár 1-2 Simplivity csomópont egy nagyon távoli irodában), ahová helyi felhasználók csatlakoznak gyors csatornákon, megőrizve a központi irányítást és menedzsmentet, és a központba csak egy minimális mennyiségű valódi, értékes és nem haszontalan adatot replikaálnak.
Természetesen a Simplivity teljes mértékben csatlakozik a OneView-hoz és az InfoSight-hoz.
Vékony és nullás kliensek
A vékony kliensek — olyan speciális megoldások, amelyeket kizárólag terminálokként használnak. Mivel a kliensen gyakorlatilag nincs teher, kivéve a csatorna fenntartását és a videó dekódolását — szinte mindig passzív hűtésű processzor található benne, egy kis boot lemezzel, csak a speciális beágyazott operációs rendszer indításához, és ez nagyjából minden. Szinte semmi sem romlik el benne, és ellopni sem érdemes. Az ára alacsony, és semmilyen adat nem tárolódik benne.
Létezik egy külön kategória a vékony kliensek között, úgynevezett nullás kliensek. Az alapvető különbségük a vékony kliensekkel szemben, hogy nincs még beágyazott általános célú operációs rendszerük sem, és kizárólag firmware-rel rendelkező mikrochipről működnek. Gyakran speciális hardveres gyorsítók is találhatók bennük a videófolyam terminálprotokollokban, mint például a PCoIP vagy HDX dekódolására.
Annak ellenére, hogy a nagy „Hewlett Packard” különálló HPE-re és HP-ra bontott, nem hagyhatjuk figyelmen kívül a HP gyártású vékony klienseket.
A választék széles, minden ízlésnek és igénynek megfelelően — egészen a többmonitoros munkahelyekig hardveres videófolyam gyorsítással.
HPE szolgáltatás az Ön távmunkájához
Utolsóként, de nem utolsósorban, szeretném megemlíteni az HPE szolgáltatást. Túl hosszú lenne felsorolni az összes HPE szolgáltatási szintet és lehetőséget, de legalább egy rendkívül fontos ajánlat létezik a távmunkával kapcsolatosan. Nevezetesen — az HPE vagy az engedéllyel rendelkező szervizközpont szolgáltató mérnöke. Ön távmunkában dolgozik, a kedvenc nyaralójában, a méhecske zúgását hallgatva, míg az HPE szakembere, aki a adatközpontba érkezett, a szervereiben kicseréli a meghibásodott diszkeket vagy tápegységet.
HPE CallHome
A mai körülmények között, a mozgáskorlátozások idején, a Call Home funkció soha nem volt ennyire aktuális. Bármely HPE rendszer, amely rendelkezik e funkcióval, önállóan értesítheti a HPE támogatási központot egy hardveres vagy szoftveres hibáról. Nagy valószínűséggel a cserealkatrész és/vagy a szervizmérnök még azelőtt megérkezik Önhöz, hogy észrevenné a problémákat és a termelékenységgel kapcsolatos hibákat.
Személy szerint javaslom ennek a funkciónak a bekapcsolását.
Forrás: habr.com
