Täna jagan teiega lugu. Lugu arvutitehnika arengust ja kaug-töökohtade tekkest kaugetest aegadest tänapäevani.
IT areng
Peamine järeldus IT ajaloost on...
Selgelt on nähtav, et IT areneb spiraalselt. Samad lahendused ja kontseptsioonid, mis visati kõrvale kümneid aastaid tagasi, saavad uue tähenduse ja hakkavad edukalt toimima uutes tingimustes, uute ülesannete ja uute võimalustega. Selles osas ei erine IT üheski mõttes teistest inimteadmiste valdkondadest ja Maa ajaloost laiemalt.
Kauges minevikus, kui arvutid olid suured
„Arvan, et maailmas on turgu umbes viiele arvutile,” ütles IBM-i juht Thomas Watson 1943. aastal.
Varajane arvutitootmine oli suur. Ei, vale - varajane tehnika oli tohutu, hiiglaslik. Täielik arvutusmasin kattis pindala, mis võrdus spordisaali suurusega, ja maksis täiesti uskumatu hinna. Näitena võib tuua ferromagnetilised rõngaste mälumoodulid (1964).
See moodul on suurusega 11 cm * 11 cm ja mahutavusega 512 baiti (4096 bitti). Kapp, mis on täielikult täidetud nende moodulitega, oli vaevalt sama mahuga nagu aegunud 3,5-tolline diskett (1,44 MB = 2950 moodulit) ning tarvitas sellegipoolest märkimisväärset elektrienergiat ja kuumenes nagu rong.
Just suurte mõõtmete tõttu on seotud ka ingliskeelne termin, mis viitab programmikoodi tõrgete leidmisele — "debugging". Üks esimesi programmimaailma pioneeridest, Grace Hopper (jah, naine), mereväe ohvitser, tegi 1945. aastal toimingute päevikusse märke pärast tõrgete uurimist programmis.
Kuna moth (öökull) on üldiselt bug (putukas), siis kogu toimuvaid probleeme ja nende lahendamiseks tehtud katseid teatati personalitöötajate seas "debugging" (otse küll ehk mõne eemaldamine) terminit kasutades, mistõttu jäi tarkvaraprobleemide ja koodivea nimeks tõrge ning tõrgete leidmine debagimiseks.
Elektroonika ja eelkõige pooljuhtide arengu käigus hakkasid masinate füüsilised mõõtmed vähenema ning arvutusvõimsus, vastupidi, suurenema. Kuid isegi sel juhul polnud võimalik anda igale inimesele isiklikku arvutit.
„Ükski põhjus ei tohiks kedagi sundida oma arvutit kodus hoidma” — Ken Olsen, DEC asutaja, 1977.
70ndatel tutvustatakse terminit miniarvuti. Mäletan, et kui esmakordselt sellele terminile mitmeid aastaid tagasi silma peale viskasin, kujutasin ette midagi, mis meenutab netbook'i, praktiliselt käeshoitavat seadet. Ma ei oleks saanud olla rohkem vale.
Mini — see on vaid võrreldes tohutute arvutikeskustega, kuid see on endiselt mitu riidekappi täis seadmeid, mille hind ulatub sadadesse ja miljonitesse dollaritesse. Kuid arvutusvõimsus oli juba piisavalt tõusnud, et mitte alati olla 100% koormatud, ja sellega ka arvutid hakkasid kergesti kätte saama üliõpilastele ning ülikoolide õppejõududele.
Ja siis tuli tema!
Vähemalt mõned inimesed ei mõtle inglise keele ladinakeelsetele juurtele, kuid just tema tõi meile kaugjuurdepääsu, nagu me seda nüüd tunneme. Terminus (ladina) — lõpp, piir, siht. T-800 Terminatori eesmärk oli lõpetada John Connori elu. Samuti teame, et transiidijaamu, kus toimub reisijate üles- ja maha laadimine või kauba laadimine ja mahalaadimine, kutsutakse terminalideks — marsruutide lõpp-punktideks.
Seetõttu tekkis terminali juurdepääsu kontseptsioon ning te saate näha maailma kõige kuulsamat terminali, mis elab endiselt meie südames.
DEC VT100 nimetatakse terminaliks, kuna see lõpetab teabe rea. Sellel on tegelikult null arvutusvõimsust ning selle ainus ülesanne on kuvada suurtelt masinatelt saadud teavet ja edastada klaviatuurilt sisend masinale. Ja hoolimata sellest, et VT100 füüsiliselt enam ei eksisteeri, kasutame me neid endiselt täiel rinnal.
Meie päevad
“Meie päevad” hakkaksin ma mõõtma 80-ndate algusest, mil turule tulid esimesed laiemale publikule kergesti kättesaadavad protsessorid, millel oli mingisugune mõtestatud arvutusvõime. Traditsiooniliselt peetakse selle ajastu peamiseks protsessoriks Intel 8088 (x86 perekond), mis on võidukana arhitektuuri algataja. Mis on siis põhimõtteline erinevus 70-ndate kontseptsiooniga?
Esmakordselt ilmneb trend, kus teavetöötlemine liigub keskelt ääre poole. Kõik ülesanded ei vaja meeletut (võrreldes nõrkade x86-ga) peamisea või isegi miniarvuti võimsust. Intel ei seisa paigal, 90ndatel toob välja Pentiumi seeria, mis sai tõeliselt esimese massilise koduversiooni Venemaal. Need protsessorid suudavad juba palju rohkemat, kui lihtsalt kirja kirjutamine – need võimaldavad ka multimeedia kasutamist ja töötavad väikeste andmebaasidega. Tegelikult kaob väikese ettevõtte jaoks täielikult vajadus serverite järele – kõik funktsioonid saab täita äärepoolsetes kliendimasinates. Iga aastaga muutuvad protsessorid aina võimsamaks ning erinevus serverite ja isiklike arvutite vahel arvutusvõimsuse osas kahaneb, jäädes sageli alles ainuselt toite varundamine, kuumavahetuse tugi ja spetsiaalsed korpused rack-montaažiks.
Kui võrrelda tänapäevaseid kliendiprotsessoreid, mis näivad 90ndate Intel'i rasketest serveritest ‘naljakad’ administraatorite jaoks, siis tekib tõeliselt veider tunne.
Vaatame vana tuttavat, kes on peaaegu minu vanune. Cray X-MP/24 aastast 1984.
See masin kuulus 1984. aasta superarvutite tippu, olles varustatud kahe 105 MHz protsessoriga ja saavutades tipptasemel arvutusvõimsuse 400 MFlops (miljonit liugoperatsiooni). Just see masin, mis on pildil, oli USA NSA krüptograafialaboris ja selle ülesanne oli murda koode. Kui konverteerida 15 miljonit dollarit 1984. aastast 2020. aasta dollariteks, oleks hind 37,4 miljonit, või 93 500 dollarit / MFlops.
Masinas, millel ma neid ridu kirjutan, on 2017. aasta Core i5-7400 protsessor, mis pole sugugi uus, ja isegi oma väljalaskmise aastal oli see kõige noorem neljatuumaline keskmise taseme lauaarvuti protsessor. 4 tuuma 3.0 GHz baassagedusel (3.5 Turbo Boostiga) ja kahekordne hüpertekitus (HyperThreading) annavad erinevate testide kohaselt 19 kuni 47 GFlops jõudlust, hinnaga 16 tuhat rubla protsessori kohta. Kui kogu masin kokku panna, võiks selle maksumuseks arvestada 750 dollarit (2020. aasta 1. märtsi hinnad ja kursid).
Lõppkokkuvõttes saame tänapäevaste keskmiste lauaarvutiprotsessorite 50–120-kordse üleoleku kümne parima superarvuti üle, mis oli möödunud ajaloos, ning MFlopsi ühekordse kulu langus muutub täiesti uskumatu 93500 / 25 = 3700 korda.
Miks on meile endiselt vajalikud serverid ja arvutuste keskne koondamine, kui meil on sellised võimed perifeerias – see on resoluutselt arusaamatu!
Tagasipöördumine – spiraal tegi pöörde
Sõrmedeta tööjaamad
Esimene signaal, et arvutuste viimine perifeeriasse ei jää lõplikuks, oli sõrmedeta tööjaamade tehnoloogia ilmumine. Kui tööjaamad on ettevõtte alal laiali jaotatud ning eriti saastatud ruumides, tekib väga tõsine vajadus nende jaamade haldamise ja toe järele.
Ilmuvad mõisted „koridoriaeg” – see on see protsent ajast, mil tehnilise toe töötaja viibib koridoris, teel probleemi juurde tooma. See aeg on tasuline, kuid täiesti ebaefektiivne. Erilise rolli mängivad kõvakettade rikkeid, eriti määrdunud ruumides. Eemaldame tööjaamast ketta, teeme kõik üle võrgu, sealhulgas käivitamise. Võrguadapter saab lisaks DHCP serverilt aadressile ka täiendavat teavet – TFTP serveri aadress ja käivituspildi nimi, laadib selle juhuslikku mällu ja käivitab masina.
Lisaks väiksemale rikkete arvule ja vähendatud koridoriajale ei pea seadet enam kohapeal seadistama, vaid lihtsalt tuua uus ja viia vana diagnostikale varustatud töökohta. Kuid see pole veel kõik!
Ilma kettata jaamad muutuvad oluliselt turvalisemaks – kui keegi peaks ruumi sisenema ja kõik arvutid ära vastu viima, on see vaid seadme kaotamine. Andmeid ei salvestata ilma kettata jaamadesse.
Mäletame seda hetke, et küberturvalisus mängib üha suurenevat rolli pärast infotehnoloogia "muretu nooruse" aega. Ja IT-sse tungivad üha enam hirmuäratavad ja olulised kolm tähte — GRC (Governance, Risk, Compliance), eesti keeles "Juhtimine, Risk, Vastavus".
Terminaliserverid
Väga võimsate personaalarvutite laialdane levik äärealadel ületab oluliselt üldkasutatavate võrkude arengut. 90ndate algusest kuni 2000ndate alguseni oli kliendi-serveri rakendustel keeruline toimida kitsastes kanalites, kui andmevahetus ulatus mingisse tähenduslikku ulatusse. See oli eriti keeruline kaugete kontorite jaoks, mis kasutasid modemit ja telefoniliini, mis aeg-ajalt kukkus välja või katkes. Ja…
Spiraal tegi pöörde tagasi terminalirežiimi, tuues taas esile terminaliserverite kontseptsiooni.
Tegelikult oleme tagasi 70ndates, kus neil ei olnud kliente ja arvutusvõimsus oli keskendatud. Väga kiiresti selgus, et peale puhtalt majanduslike kanalite, pakub terminali juurdepääs tohutuid võimalusi turvalise juurdepääsu korraldamiseks, sealhulgas töötamiseks kodus töötajatele või äärmiselt piiratud ja kontrollitud juurdepääsuks lepingulistele partneritele usaldamatest võrku ja kontrollimatutest seadmetest.
Kuid terminaliserveritel, hoolimata nende eelistest ja progressiivsusest, oli ka mitmeid miinuseid — madal paindlikkus, lärmakate naabrite probleem, serveripõhine Windows jne.
Proto VDI sünnilood
Kuid tõsi on see, et 00ndate alguses ja keskel tõusis tööstuslik virtualiseerimine x86 platvormile. Keegi väljendas lihtsalt õhus hõljuvat ideed: miks mitte keskendada kõiki kliente serverite terminalifarmides, vaid anda igale inimesele tema isiklik virtuaalmasin koos kliendi Windowsi ja isegi administraatori juurdepääsuga?
Paksust klientidest loobumine
Koosel koos istungite ja operatsioonisüsteemide virtualiseerimisega arenes lähenemine, mis kergendas kliendi funktsiooni rakenduse tasandil.
Loogika selle taga oli üsna lihtne, kuna personaalarvutid ei olnud ikka veel kõigil, internet ei olnud samuti kõigile kergesti kättesaadav, ja paljud said ühendust vaid internetikohvikutes, kus õigused olid, õrnalt öeldes, väga piiratud. Tegelikult sai käivitada vaid brauseri. Brauserist sai operatsioonisüsteemi lahutamatu osa, internet on kindlalt meie ellu sisenemas.
Teisisõnu, paralleelselt oli tõusutrend loogika viimiseks kliendilt keskusesse veebirakenduste kaudu, millele pääsemiseks on vajalik ainult kõige lihtsam klient, internet ja brauser.
Ja me ei saanud mitte lihtsalt sinna, kus me alustasime — null-klientidelt ja keskserveritelt. Me jõudsime sinna mitmete iseseisvate teede kaudu.
Virtual Desktop Infrastructure
Brokker
2007. aastal turuliider tööstuslikus virtualiseerimises, VMware, tutvustas oma toote VDM (Virtual Desktop Manager) esimest versiooni, mis oli tegelikult esimene toode alles tekkivas virtuaalsete lauaarvutite turul. Loomulikult ei pidanud terminaliserverite liider Citrix kaua ootama vastust, sest 2008. aastal, pärast XenSource'i omandamist, ilmus XenDesktop. Ilma kahtluseta olid ka teised tegijad oma pakkumistega, kuid ei lasku liiga sügavale ajalukku, jäädes oma kontseptsiooni juurde.
Käesolev kontseptsioon püsib siiani. VDI peamine komponent on ühenduse vahendaja.
Just see on virtuaalsete lauaarvutite infrastruktuuri süda.
Vahendaja vastutab VDI kõige olulisemate protsesside eest:
- Määrab kindlaks ühendatud kliendile saadaval olevad ressursid (masinad/sessioonid);
- Juhib vajadusel kliente masinate/sessioonide basseinide vahel;
- Suunab kliendi valitud ressurssile.
Tänapäeval võib VDI kliendiks (terminaaliks) olla sisuliselt kõik, millel on ekraan — sülearvuti, nutitelefon, tahvelarvuti, kiosk, õhuke või null klient. Vastandiks on see, mis täidab produktiivset koormust — terminaliserveri sessioon, füüsiline masin või virtuaalne masin. Kaasaegsed küpsed VDI tooted on tihedalt integreeritud virtuaalsesse infrastruktuuri ja haldavad seda automaatselt, kasutades vajadusel virtuaalmasinate käivitamist või eemaldamist.
Veidi eraldi, kuid mõnele kliendile äärmiselt oluline VDI tehnoloogia on 3D graafika riistvara kiirustoetuse tugi, mis on kriitilise tähtsusega projekteerijate või disainerite tööks.
Protokoll
Teine äärmiselt oluline osa küpsest VDI lahendusest on protokoll virtuaalsete ressursside juurde pääsemiseks. Kui jutt on ettevõtte sisevõrgus töötamisest, kus on suurepärane usaldusväärne 1 Gbps võrguühendus töökohta ja 1 ms latentsus, võib olla sisuliselt mistahes protokolli kasutamine sobiv.
Mõtlema peab, kui ühendus käib kontrollimata võrgus, mille kvaliteet võib varieeruda täiesti erinevatest tasemetest, sealhulgas kümnete kilobittide kiirusest ja ettearvamatutest viivitustest. Just selliste olukordade jaoks on vajalik tõeline kaug töö korraldamine - suvilatest, kodust, lennujaamadest ja kohvikutest.
Terminaliserverid vs kliendi VM-id
Kui VDI-d (virtuaalsed töölauainfrastruktuurid) ilmusid, näis, et terminaliserveritega on hüvasti jäetud. Miks need üldse vajalikud on, kui igalühel on oma isiklik VM?
Siiski, puhtalt majanduslikust vaatenurgast selgus, et tüüpiliste massiliste töökohtade puhul, mis on igavesti samad - ei ole seni midagi tõhusamat terminaliserverite hinna/sessiooni suhte osas. Kõikide oma eeliste juures tarbib lähenemine "1 kasutaja = 1 VM" märkimisväärselt rohkem ressursse virtuaalse riistvara ja täieliku operatsioonisüsteemi jaoks, mis halvendab tüüpiliste töökohtade majandust.
Kui rääkida tippjuhtide, mittestandardsete ja koormatud töökohtade ning vajadusest omada kõrgeid õigusi (kuni administraatori tasemeni), siis eelistatakse kasutajale määratud eraldatud virtuaalmasinat. Sellises virtuaalmasinas on võimalik ressursse individuaalselt eraldada, anda igasuguseid õigusi ja tasakaalustada virtuaalmasinaid virtualiseerimise hostide vahel kõrge koormuse korral.
VDI ja majandus
Aastaid olen kuulnud ühte ja sama küsimust — kuid kuidas on VDI odavam kui lihtsalt anda kõikidele sülearvutid? Ja aastaid olen pidanud vastama ikka ja jälle sama: tavapäraste kontoritöötajate puhul ei ole VDI odavam, kui arvutada ainult seadmete hankimise puhtad kulud. Kuidas iganes, sülearvutid odavnevad, samas kui serverid, salvestussüsteemid ja süsteemitarkvara maksavad ikka veel märkimisväärselt. Kui on aeg teie seadmeid uuendada ja loodate VDI kaudu säästa — ei, te ei säästa.
Ma varem tõin välja need hirmuäratavad kolm tähte GRC — nii et VDI ongi seotud GRC-ga. See puudutab riskijuhtimist, see on seotud andmete turvalisuse ja kontrollitud ligipääsu mugavusega. Ja tavaliselt maksavad sellised lahendused üsna palju, kui neid rakendada paljusugustele seadmetele. VDI abil muutub kontroll lihtsamaks, turvalisus paraneb ning juuksed saavad pehmeks ja siidiseks.
HPE lahendused kaugtööks
Kaugtöö ja pilvehaldus
iLO
HPE ei ole kaugserverite halduses sugugi uus tulija, naljakski on — märtsis tähistati legendaarse iLO (Integrated Lights Out) 18. sünnipäeva. Olles meenutanud oma adminni aegu 2000. aastatel, ei suutnud ma lihtsalt rahul olla. Esialgne montaaž rackidesse ja kaablite ühendamine — see oli kõik, mida tuli teha müra ja külma andmekeskuses. Kõik muu konfigureerimine, sealhulgas operatsioonisüsteemi installimine, oli võimalik teha juba töökohalt, kahe monitori ja kuuma kohvitassiga. Ja see oli 13 aastat tagasi!
Tänapäeval on HPE serverid põhjusega vaieldamatuks pikaajalise kvaliteedi standardiks — ning oluline roll selles on kaugjuhtimise kuldstandardil — iLO.
Tahan, et rõhutada HPE tegevust inimkonna kontrolli hoidmisel koroonaviiruse üle. , et kuni 2020. aasta lõpuni (vähemalt) on iLO Advanced litsents kõigile tasuta saadaval.
Infosight
Kui teie infrastruktuuris on rohkem kui 10 serverit, ja administraator ei põe igavust, siis kindlasti on suurepärane täiendus standardsetele jälgimisvahenditele HPE Infosight, mis põhineb tehisintellektil. See süsteem mitte lihtsalt ei jälgi seisundit ja ei koostaa graafikuid, vaid soovitab ka iseseisvalt edasisi meetmeid, tuginedes praegusele olukorrale ja suundumustele.
Ole nutikas, , proovi Infosight'i!
OneView
Viimasena, kuid mitte vähem tähtsana, tahan esile tuua HPE OneView - terviklik tooteportfell tohutute võimalustega kogu infrastruktuuri jälgimiseks ja haldamiseks. Ja seda kõike mitte tõusmata oma kirjutuslaualt, mis võib-olla hetkel on suvises suvekodus.
SÜS ei jää samuti alla!
Muidugi, kõik SÜS-d on kaugjuhtimisega ja jälgimisega - nii oli juba palju aastaid tagasi. Seetõttu tahan täna rääkida millestki muust, nimelt metroklusteritest.
Metroklastrid ei ole turul uus nähtus, kuid just seetõttu ei ole nad siiani liiga populaarsed – mõtted ja esimesed muljed on kangekaelsed. Loomulikult olid nad 10 aastat tagasi juba olemas, kuid maksid nagu raudtee sild. Aastad, mis on möödunud esimestest metroklastritest, on muutnud tööstust ja tehnoloogia kergemini kättesaadavaks laiadele massidele.
Ma mäletan projekte, kus andmesalvestussüsteemi osi paigutati spetsiaalselt eraldi – ühed ülivajalikud teenused metroklastrisse, teised sünkroonimiseks (kuid oluliselt odavam).
Tegelikult, 2020. aastal ei maksa metroklaster teile midagi, kui suudate korraldada kaks asukohta ja kanaleid. Ja sünkroonilise replikatsiooni kanalid vajavad täpselt samu, mis metroklastrid. Tarkvara litsentsimine on ammu juba pakettide kaudu – sünkrooniline replikatsioon tuleb kohe koos metroklastriga, ja ainus, mis hetkel säilitab ühesuunalise replikatsiooni elu, on vajadus organiseerida venitatud L2 võrk. Ja isegi see, L2 L3 peal, on juba maapinda vallutamas.
Mis on siis põhimõtteline erinevus sünkroonilise replikatsiooni ja metroklastri vahel kaugelt töötamise vaatenurgast?
Kõik on väga lihtne. Metroklaaster töötab iseseisvalt, automaatselt, alati, praktiliselt koheselt.
Kuidas näeb välja koormuse ülemineku protsess sünkroonse replikatsiooni korral infrastruktuuris, kus on vähemalt paar sada VM-i?
- Saab signaal hädaolukorra kohta.
- Vahetus analüüsib olukorda - võib rahulikult arvestada 10 kuni 30 minutit ainult signaali saamiseks ja otsuse tegemiseks.
- Juhul kui dežuurinseneridel puuduvad volitused iseseisvaks ülemineku alustamiseks - veel 30 minutit sideühenduse loomiseks isikuga, kellel on volitused, ja ametlikuks kinnitamiseks ülemise algamiseks.
- Suurte punaste nuppude vajutamine.
- 10-15 minutit ooteaegu ja mahu uuesti monteerimist, VM-ide uuesti registreerimist.
- 30 minutit IP-aadresside vahetamiseks - optimistlik hinnang.
- Ja lõpuks VM-i käivitamine ja tootmisteenuste käivitamine.
Kokkuvõttes võib RTO (äritegevuse taastumise aeg) julgesti hinnata 4 tunniks.
Võrdleme situatsiooni metroklaastriga.
- Andmesalvestussüsteem mõistab, et side metroklaasteriga on kadunud - 15-30 sekundit.
- Virtuaalhostid mõistavad, et esimene andmekeskus on kadunud - 15-30 sekundit (samal ajal kui punkt 1).
- Automaatne restart poolest kuni kolmandikuni VMs teises andmekeskuses — 10-15 minutit teenuste laadimiseks.
- Umbes sel ajal saavad valvevahetus aru, mis juhtus.
Kokku: RTO = 0 eraldi teenustele, 10-15 minutit üldiselt.
Miks aga restart ainult poolest kuni kolmandikuni VMs? Vaadake, mis asi see on:
- Te teete kõike nutikalt ja aktiveerite automaatse VM jaotuse. Tulemuseks on, et keskmiselt täitub vaid pool VMs ühes andmekeskuses. Lõppude lõpuks on metroklastrite eesmärk vähendada seisakuid, seega on teie huvides vähendada ka VM-ide arvu, mis on ohtu sattunud.
- Mõned teenused saab klasterdada rakendustasandil, jagades need erinevatesse VMsse. Vastavalt sellele kinnitatakse need paaritud VMs üksteisega nagide või lintidega erinevatesse andmekeskustesse, et teenus ei peaks seadme taaskäivitamist ootama, kui juhtub hädaolukord.
Korrektselt üles ehitatud infrastruktuuri korral, kus on laialdaselt metroklastreid, saavad ärikasutajad töötada minimaalsete viivitustega igast punktist, isegi juhul, kui andmekeskuse tasandil juhtub hädaolukord. Halvimal juhul on viivitus sama pikk kui ühe kohvi joomine.
Ja, ja muidugi töötavad metroklaastrid suurepäraselt nii HPE 3Par'i vanade variantide kui ka uute Primera mudelitega!
Kaug töökohtade infrastruktuur
Terminaliserverid
Terminaliserverite jaoks ei pea välja mõtlema midagi uut; HPE on aastaid tarninud ühte parimatest serveritest kogu maailmas. Ajatu klassika – DL360 (1U) või DL380 (2U) või AMD armastajatele – DL385. Muidugi on saadaval ka blade-serverid, nii klassikalised C7000 kui ka uus moodulplatform Synergy.
Igaühe maitsele, igaühe värvile, maksimum sessioonid serveris!
“Klassikaline” VDI + HPE Simplivity
Siin, rääkides “klassikalisest VDI-st”, mõtlen kontseptsiooni 1 kasutaja = 1 VM kliendipoolse Windowsiga. Ja loomulikult ei ole VDI koormusele lähedasem ega tuttavam pole hüperkonvergentsüsteemidele, eriti dedupeerimise ja kompressiooniga.
Siin saab HPE pakkuda nii oma hüperkonvergentsplatformi Simplivity kui ka servereid / sertifitseeritud sõlmi partnerite lahenduste jaoks, näiteks VSAN Ready Nodes VDI ehitamiseks VMware VSAN infrastruktuuri peal.
Rääkigem veidi rohkem meie Simplivity lahendusest. Nagu nimi viitab, on keskmes lihtsus. Lihtsus juurutamisel, lihtsus haldamisel ja lihtsus skaleerimisel.
Hüperkonvergentsed süsteemid on praeguseks üks kuumemaid teemasid IT-s ning erinevate tasemete tootjaid on umbes 40. Gartneri maagilise ruudu kohaselt on HPE globaalselt Top 5 seas ja kuulub liidrite ruutu — nad mõistavad nii tööstuse suundi kui suudavad selle teadlikkuse ka riistvarasse viia.
Arhitektuuriliselt on Simplivity klassikaline hüperkonvergente süsteem, mis koosneb kontrolleri virtuaalmasinatest, mis tähendab, et see suudab toetada erinevaid hüperviisoreid, erinevalt integreeritud hüperviisorite süsteemidest. Tegelikult toetatakse aprilli 2020 seisuga VMware vSphere'i ja Microsoft Hyper-V-d, ning plaanid KVM-i toetamiseks on välja kuulutatud. Simplivity keskne omadus alates turule tulekust on olnud riistvara kiiruskompressioon ja deduplication spetsiaalse kiirendardi abil.
Oluline on märkida, et tihendamine koos dedupeeringuga on globaalselt aktiivne ja pidevalt sisse lülitatud, seega ei ole see valikuline funktsioon, vaid lahenduse arhitektuur.
HPE väidab kindlasti veidi liialdades 100:1 efektiivsust, arvutades seda pigem erilisel moel, kuid ruumi kasutuse efektiivsus on tõepoolest väga kõrge. Lihtsalt number 100:1 on liiga kaunis. Vaatame, kuidas Simplivity tehniliselt teostatud, et näidata selliseid numbreid.
Snapshots. Snapshots (hetkesalvestused) on 100% õigesti teostatud ReW (Redirect-on-Write) meetodil, mis tähendab, et need toimuvad koheselt ja ei põhjusta jõudluse langust. Erinevalt näiteks mõnest muust süsteemist. Miks on vajalikud kohalikke snapshots ilma tasu? See on väga lihtne: RPO vähendamiseks 24 tunnilt (keskmine RPO varundamise puhul) minutiteni või isegi sekunditeni.
Varundus. Snaipshot varundub varukoopiast ainsana selle poolest, kuidas virtuaalmasinate haldussüsteem seda tajub. Kui masina kustutamisel kustub ka kõik muu – siis oli see snaipshot. Kui midagi jäi alles – siis on see varukoopia. Seega võib iga snaipshot olla täielik varukoopia, kui see on süsteemis märgitud ja mitte kustutatud.
Loomulikult paljud vastavad — kuidas see saab olla varukoopia, kui see salvestatakse samas süsteemis? Siin on väga lihtne vastus vastuküsimuse näol: kas teil on vormistatud ohumudel, mis kehtestab varukoopia säilitamise reeglid? See on täiesti õige varukoopia võrreldes faili kustutamisega VM-i sees, see on varukoopia võrreldes kogu VM-i kustutamisega. Kui on vajalik säilitada varukoopia ainult eraldi süsteemis, on valik: selle snaipshoti replikatsioon teisele Simplivity klastri või HPE StoreOnce'ile.
Ja siin selgub, et selline arhitektuur sobib ideaalselt igasuguste VDI-de jaoks. Lõppude lõpuks on VDI sadu või isegi tuhandeid väga sarnaseid masinateid sama operatsioonisüsteemi ja samade rakendustega. Üks globaalne deduplichatsioon suudab kõik selle kokku suruda, isegi mitte 100:1, vaid palju paremini. 1000 virtuaalmasina arendamine ühe šablooni põhjal? Ei ole mingit probleemi, need masinad registreeruvad vCenteris kauem kui kloonitakse.
Erakordsete toimivuse nõudmistega kasutajate ja nende jaoks, kellele on vajalikud 3D-kiirendid, loodi Simplivity G seeria.
Selles seerias ei kasutata riistvaralist deduplichatsiooni kiirendit, mistõttu on node'i ketaste arv vähenenud, et kontroller saaks programmiliselt hakkama. Selle tulemusena vabastatakse PCIe slotid kõikideks muude kiirendite jaoks. Samuti on node'i mälu maht kahekordistunud kuni 3TB kõige nõudlikumate koormuste jaoks.
Simplivity sobib ideaalselt geograafiliselt jaotatud VDI infrastruktuuride korraldamiseks andmete replikatsiooniga kesksetesse andmekeskustesse.
Sarnane VDI arhitektuur (ja mitte ainult VDI) on Venemaa tingimustes eriti huvitav — suured vahemaad (ja seega viivitused) ning kaugel mitte ideaalsed kanalid. Loobetakse piirkondlikud keskused (või isegi lihtsalt 1-2 Simplivity sõlme väga kauges kontoris), kuhu ühendatakse kohalikud kasutajad kiirete kanalite kaudu, säilitades täieliku kontrolli ja haldamise keskelt, ning keskselt replitseeritakse vaid väike kogus tõeliselt väärtuslikke, mitte prügikonteinerisse kuuluvaid andmeid.
Muidugi ühildub Simplivity täielikult OneView ja InfoSightiga.
Peenikesed ja nullklientide seadmed
Peenikesed kliendid on spetsialiseeritud lahendused, mis on ette nähtud kasutamiseks ainult terminalidena. Kuna kliendile ei lange praktiliselt mingit koormust peale kanali hoidmise ja video dekodeerimise — on seal peaaegu alati ventileerimata protsessor, väike käivitusketas, mis on mõeldud spetsiaalse sisseehitatud operatsioonisüsteemi käivitamiseks, ja sisuliselt kõik. Nendes on peaaegu võimatu katki minna, ja varastamine on mõttetu. Hind on madal ja andmeid ei salvestata.
On olemas eriline õhuke klientide kategooria, nn nullklientide kategooria. Nende peamine erinevus õhukestest klientidest on see, et neil puudub isegi integreeritud üldotstarbeline opsüsteem ja nad töötavad ainult mikroskeemilt, millel on sisseehitatud tarkvara. Tihti on nendesse paigaldatud spetsiaalsed riistvarakihutajad videovoo dekodeerimiseks terminaliprotokollides, nagu PCoIP või HDX.
Hoolimata suurte 'Hewlett Packard'i' eraldamisest eraldi HPE ja HP brändideks, ei saa mainimata jätta HP valmistatud õhukesi kliente.
Valik on lai, vastavalt igale maitsele ja vajadusele — kuni mitme monitoriga töökohtadeni koos riistvaralise videovoogude kiirusel.
HPE teenus teie kaugtöö jaoks
Ja viimasena, kuid mitte vähem tähtsana, tahan mainida HPE teenust. Olgu öeldud, et HPE teenuse kõiki tasemeid ja võimalusi oleks liiga pikk loetleda, kuid vähemalt on olemas üks äärmiselt oluline pakkumine kaugtöö tingimustes. Nimelt HPE/autoriseeritud teeninduskeskuse teenindusinsener. Te jätkate tööd kaugtööna, nautides oma lemmik suvekodust mesilaste mõnusaid helisid, samal ajal kui HPE esindaja, kes külastab andmekeskust, vahetab teie serverites kettaid või vigast toiteallikat.
HPE CallHome
Tänapäeva tingimustes, mil liigelda on piiratud, on funktsioon Call Home enam kui kunagi varem aktuaalne. Iga HPE süsteem, millel on see funktsioon, saab ise HPE tugikeskusele teavitada riistvara või tarkvara tõrkest. On täiesti tõenäoline, et varuosa ja/või teenindusinsener jõuab teieni juba enne, kui te märkate tootmisprobleeme ja -rikkumisi.
Isiklikult soovitan tungivalt selle funktsiooni aktiveerimist.
Allikas: habr.com
