Այսօր ես ձեզ պատմելու եմ մի պատմություն: Համակարգչային տեխնոլոգիայի_evoluciya պատմությունը և հեռահար աշխատանքային վայրերի ստեղծումը հնագույն ժամանակներից մինչ օրս:
Տեղեկատվ технологի զարգացումը
Այն հիմնական խոսքը, որը կարելի է հայտնել IT պատմությունից՝ սա …

Իհարկե, IT-ն զարգանում է ստորջյա: Միևնույն լուծումները և գաղափարները, որոնք բազմաթիվ տարիներ առաջ մերժվել էին, նոր իմաստ հավաքում են և հաջողությամբ սկսում աշխատել նոր պայմաններում, նոր խնդրանքների և նոր հզորությունների տակ: Այս ասպարեզում IT-ն ոչնչով տարբերվում է մարդկային գիտելիքի և Երկրի պատմության մյուս բնագավառներից:

Շատ ժամանակ առաջ, երբ համակարգիչները մեծ էին
«Ես կարծում եմ, որ աշխարհում կա բիզնես մոտավորապես հինգ համակարգիչների համար», այսօր IBM-ի նախագահ Թոմաս Ուոթսոնը 1943 թվականին:
Ավելի վաղ համակարգչային տեխնիկան մեծ էր: Ոչ, սխալ է, ավելի վաղ տեխնիկան ի՞նչ-որ անասելի, արարչական: Լիովին հաշվարկչական մեքենան occupied լայնքից, համեմատելի սպորտային դահլիճի տարածքի վրա, ուներ նաև անսովոր արժեթղթեր: Ինչպիսին են օրինակ, արագ հիշողության մոդուլի ֆերիտային օղակներ (1964):

Այս մոդուլը ունի 11 սմ * 11 սմ չափսեր, և կարողություն 512 բայթ (4096 բիթ): Տուփը, ամբողջովին այս մոդուլներով լեցուն, հազիվ թե ուներ հին սկավառակի 3,5'' (1.44 ՄԲ = 2950 մոդուլ) կարողություն, այդ ժամանակ սպառում էր զգալի էլեկտրական հզորություն և տաքանում էր ինչպես շարժիչ:
Այս մեծ չափերի հետ կապված է նաև՝ անգլերեն անվանումը ծրագրային կոդի համընկնումը՝ «debugging»: Զանգվածի պատմության մեջ առաջին ծրագրավորողներից ՝ Գրեյս Հոփփը (այո, այո, կին), ռազմական ընդհանուր նվագարկման զեկուցագրում կատարեց գրառում 1945 թվականին ծրագրի սխալի հետաքննումի մասին:

Քանի որ moth (մոծակ) իհարկե bug (ժամանակվա ընտանիքի թևավոր) ամբողջովին կարծում եմ, հետո խնդիրը և անձնակազմի կողմից որոշակի գործողությունները ղեկավարությանը հաշվետվություն տրվեցին որպես «debugging» (բառացիորեն կոտրելու), խափանումի և կոդի սխալի համար ամուր սերտորեն առանձնացավ bug անունը, իսկ debugging-ը դարձավ debug:
Իրականում էլեկտրոնիկայի և մասնավորապես կիսահաղորդչային տեխնիկայի զարգացման գործընթացում, տեխնիկաները ուսումնասիրել բացառիկ անկումը, իսկ հաշվարկչական կարողությունները, հակառակաբար, աճում էին: Բայց նույնիսկ այդ դեպքում, խոսքն այն էր, որ անհատական համակարգիչներին ոչ մեկին չի կարելի տալ:
«Ոչ մի պատճառ չկա, որ որևէ մեկը ցանկանում է համակարգիչ ունենալ իր տանը» — Քեն Օլսեն, DEC-ի հիմնադիր, 1977:
70-ականներին առաջանում է մինի համակարգիչների հասկացությունը: Վստահ եմ, որ երբ առաջին անգամ ընթերցել էի այս տերմինը տարիներ առաջ, ինձ երևակայությունը զգում էր ինչ-որ տեսակի նետբուք, գրեթե ձեռքիս համանման: Չէի կարող լինել ավելի հեռու ճշմարտությունից:

Մինի — այն միայն համեմատաբար մեծ մեքենաների սրահների հետ, բայց այն դեռևս մի քանի պահարաններ է, որտեղ կա սարքավորումներ, որոնց արժեքը հասնում է հարյուր հազարների և միլիոնների դոլար։ Այնուամենայնիվ, հաշվողական հզորությունը արդեն այնքան է աճել, որ միշտ չէ, որ լցված էր 100%-ով, և այդ դեպքում համակարգիչները սկսել են հասանելի լինել համալսարանների ուսանողների և դասախոսների համար։
Եվ այստեղ նա եկավ!

Շատերը չեն մտածում անգլերենի լատինական արմատների շուրջ, բայց հենց նա մեզ բերեց հեռավոր մուտքը, ինչպես մենք գիտենք այն հիմա։ Terminus (լատ) — վերջ, սահման, նպատակ։ Տերմինատոր T800-ի նպատակն էր վերջ տալ Ջոն Կոնորին։ Նույնպես գիտենք, որ տրանսպորտային կայանները, որտեղ կատարվում է ուղևորների բարձրացման և իջեցման կամ բեռների բեռնավորման և բեռնաթողման պրոցես, կոչվում են տերմինալներ` երթուղիների վերջնակետի։
Ուստի muncul концепция терминального доступа, и вы можете увидеть самый известный в мире терминал, до сих пор живущий в наших сердцах.

DEC VT100-ը կոչվում է տերմինալ, քանի որ ավարտում է տեղեկատվական գիծը։ Ունի իրականում զրոյական հաշվողական հզորություն, և նրա միակ խնդիրը — ցուցադրել ստացված մեծ մեքենայից տեղեկատվությունը, և փոխանցել մեքենա մուտք teclado-ի։ Եվ այն բանում, որ VT100-ները ֆիզիկապես վաղուց մեռել են, մենք դեռևս լիովին օգտվում ենք դրանցից։

Մեր օրերը
«Մեր օրերը» ես սկսի հաշվել 80-ականների սկզբից, երբ առաջին անգամ համընդհանուր հասանելի դարձան որոշ գաղտնի պրոցեսորներ, որոնք ունեին որևէ նշանակալի հաշվարկային հզորություն։ Ընդհանուր առմամբ համարվում է, որ այս դարաշրջանի գլխավոր պրոփեսորը Intel 8088-ն է (x86 ընտանիք)՝ որպես հաղթող ճարտարապետության նախօրինակ։ Ի՞նչն է իսկական տարբերությունը 70-ականների կոնցեպցիայի հետ:
Առաջին անգամ առաջանում է տեղեկատվության մշակման տեղաշարժը կենտրոնից դեպի ծայր։ Շատ խնդիրներ չեն պահանջում մաիծ (x86-ից թույլ) մենֆրեյմի կամ նույնիսկ մինի-համակարգչի խելահաս հզորություն։ Intel-ը չի կանգնում տեղում, 90-ականներին թողարկում է Pentium ընտանիքը, որը իսկապես առաջին զանգվածային տնային համակարգիչն էր Ռուսաստանում։ Այս պրոցեսորները արդեն շատ բան կարող են անել, ոչ միայն նամակ գրել — այլ նաև մուլտիմեդիա և աշխատել փոքր տվյալների բազաների հետ։ Իրականում փոքր բիզնեսի համար լիովին անհնար է սերվերների անհրաժեշտությունը — ամեն ինչ կարելի է կատարել ծայրում, հաճախորդական մեքենաներում։ Քաղաքները տարին մեկ ավելի ուժեղ են, և տարբերությունը սերվերների և անձնական կոմպյուտերների միջև հաշվողական հզորության տեսանկյունից越来越 փոքր է, հաճախ մնալով միայն էներգիայի պաշարումը, չարափոխանակում, և հատուկ կորպուսներ՝ սարքավորումների տեղադրման համար:
Եթե համեմատենք ժամանակակից հաճախորդական պրոցեսորները «ժխտական» համարի համար ադմինիստրատորների ծանր սերվերների 90-ականներին Intel-ի հետ՝ սուպեր կենտրոններ, ապա իսկապես մի քիչ անհարմար է:
Արի նայենք այս ծերունուն, որն ավելի թե ոչ, իմ տարեկիցն է: Cray X-MP/24 1984 թվականին:

Այս մեքենան ընդգրկվել է 1984 թվականի սուպերգիտակների լավագույն տասնյակում, ունենալով 2 պրոցեսոր 105 MHz հաճախականությամբ և 400 MFlops (միլիոներ պահող օպերացիաներ) պիկային հաշվարկային հզորություն: Ճիշտ այն մեքենան, որ պատկերված է լուսանկարում, գտնվում էր ԱՄՆ Գիտությունների ազգային լաբորատորիայի крипտոգրաֆյանան, և զբաղվում էր կոդերի խախտմամբ: Եթե 1984 թվականի 15 միլիոն դոլարը փոխարկենք 2020 թվականի դոլարների, ապա առկա արժեքը կ составит 37,4 միլիոն, կամ 93 500 դոլար / MFlops:

Այն մեքենայում, որի վրա ես գրում եմ այս տողերը, տեղադրված է Core i5-7400 պրոցեսորը 2017 թվականից, որ ոչ այնքան նոր է, և նույնիսկ իր թողարկման տարում եղել է ամենաերիտասարդ 4-մատնջային պրոցեսորների միջին մակարդակների: 4 պրոցեսոր 3.0 GHz հենաս_FREQ-ով (3.5 Turbo Boost-ով) և HyperThreading տեխնոլոգիայի կրկնապատկումը տալիս են 19-ից մինչև 47 GFlops հզորություն տարբեր թեստերի ժամանակ, պրոցեսորի արժեքը 16,000 ռուբլի: Եթե ամբողջ մեքենան հավաքենք, նրա արժեքը կարելի է ընդունել 750 դոլար (2020 թվականի եղանակի և փոխարժեքի համաձայն):
Վերջում ստանում ենք առնվազն միջին десктոպ պրոցեսորի գերազանցությունը մեր օրերում 50-120 անգամ ու սուպերգիտակներից, որոնք գտնվում էին 10 լավագույնների շարքերում, իսկ MFlops-ի բացառվելու արժեքի փոթորկին հասնում է ահռելի 93,500 / 25 = 3700 անգամ:
Ինչու է մեզ դեռ անհրաժեշտ սերվերներ ու հաշվարկների կենտրոնացում նման ուժեղ մատակարարություններով՝ իսկապես անհասկանալի է:
Հակադարձ թռիչք — պտույտը կատարել է թեքված:
Բեսդիսկային կայաններ:
Հաշվարկների տեղափոխման առաջին ազդանշանը, որ չի լինելու վերջնական արդյունքը, եղավ բեսդիսկային աշխատանքային կայանների տեխնոլոգիայի հայտնությունը: Աշխատանքի կայանների տարածքում զգալի խոշորեցման դեպքում, հատկապես աղտոտված սենյակներում, հարցը կառավարման և աջակցման նկատմամբ շատ մտահոգիչ է:

Հայտնվում է «կոլիդորային ժամանակ» հասկացությունը ՝ այն ժամանակաընթացը, երբ տեխնիկական աջակցման աշխատակիցը գտնվում է կոլիդորում, ճանապարհին դեպի խնդիր ունեցող աշխատակիցը: Այս ժամանակը վճարվում է, բայց բացարձակապես արտադրողական չի:

Փոքր քանակությամբ փչացած մասեր և կոլիդորային ժամանակի կրճատումը, մեքենան այժմ հնարավոր է ուղղաթիռի տեղում պատրաստել, իսկ פשוט նորն բերել, իսկ հինը վերցնել ախտորոշման համար սարքերով ձեռքբերմայից: Բայց դա դեռ ոչ הכל է!
Անձրևաշոս ստացիան զգալիորեն ավելի անվտանգ է դառնում, քանի որ, եթե միջընդրիչներից մեկը ներխուժի և խլի բոլոր համակարգիչները, դա պարզապես սարքավորումների կորուստ է: Անձրևաշոս ստացիաներում տվյալներ չեն պահվում:
Հիշենք այս պահը, ԻԲ-ն սկսում է խաղալ ավելի մեծ դեր «տեղեկատվական տեխնոլոգիաների» «անփույթ մանկություն» դարաշրջանից հետո: Իսկ ՏՏ-ում increasingly մուտք են գործում վտանգավոր և կարևոր 3 տառը՝ GRC (Governance, Risk, Compliance), կամ հայերենով «Կառավարման, Պորտֆանի, Համապատասխանություն»:

Տերմինալային սերվերներ
Համարայն տարածվածությունը օրեցօր ավելի ու ավելի հզոր անձնական համակարգիչների շուրջ, բավականին շուտ գերազանցեց ընդհանուր ցանցերի զարգացմանը: Դասական 90-ականների-սկզբի 00-ականների հաճախորդ-սերվերային կիրառումները չէին գործում լավ նեղ ալիքների միջոցով, եթե տվյալների փոխանակությունը նշանակալի արժեքներ չուներ: Մ especialmente սա զգալի դժվարություններ էր առաջացնում հեռավոր գրասենյակների համար, որոնք միացվում էին մոդեմի և հեռախոսային خطوطի միջոցով, որը, երբեմն, ձգվում կամ ընդհատվում էր: Եվ…
Սփիրալն վերադարձել է և կրկին հայտնվելու է տերմինալային ռեժիմում, տերմինալային սերվերների կոնցեպցիայով:

Իբր մենք վերադարձրել ենք 70-ականներին նրանց զրո հաճախորդներով և հաշվողական աշխատունակության կենտրոնացմանն: Շատ արագ պարզ դարձավ, որ միմիայն տնտեսական պատճառները, զուգահեռ ունենալով տերմինալային հասանելիություն, առաջարկում են մեծ հնարավորություններ անվտանգ մուտք կազմակերպելու համար, այդ թվում՝ աշխատել տնից աշխատակիցների համար, կամ կտրուկ լիովին կանխատեսվող մուտք ենթակայուն, չհաստատված ցանցերից և չհաստատված/ոչ վերահսկվող սարքերից:
Այնուամենայնիվ, տերմինալային սերվերներն, իրենց բոլոր առավելություններով ու առաջադեմությամբ, ունեն մի շարք թերություններ. ցածր ճկունություն, աշխույժ հարևանի խնդիրը, խիստ սերվերային Windows և այլն:
Վիճակագրական VDI-ի ծնունդը

Սակայն 00-ականների սկզբին և միջինում արդեն ամեն դեպքում սկսում էր ստանալ արդյունաբերական վիրտուալիզացիան x86 հարթությունում: Եվ ոմանք պարզապես առաջարկեցին օդում գոյություն ունեցող գաղափարը.`«Ահա, եկեք բոլոր հաճախորդներին կենտրոնական սերվերային կայաններում փոխարեն, մենք յուրաքանչյուրին կտանք իր անձնական VM-ները նոյին Windows-ով և անգամ ադմինիստրատորային մուտքով»:
Ծանր հաճախորդներից հրաժարում
Վիրտուալիզացիայի սессիաների և ОС-ի հետ զուգահեռ զարգանում էր մոտեցումը, որը կապված էր հաճախորդի ֆունկցիան տարածքի մակարդակով թեթևացնելու հետ:
Այս տրամաբանությունը բավականին պարզ էր, իսկ պատրաստված անձնական նոթբուքներից դեռ շատերը չունեցան, ինտերնետը նույնպես գրեթե բոլորիս չէր հասանելի, և רבים միայն կարող էին միանալ ինտերնետ-կոֆեներից՝ շատ սահմանափակ, մեղմ ասած, իրավունքներով: Իրականում, ամեն ինչ, ինչի վրա հնարավոր էր գործարկել` բրաուզերն էր: Բրաուզերները դարձան անհրաժեշտ ախպեր ОС-ի, ինտերնետը հաստատապես մտնում էր մեր կյանք:
Դա նշանակում է, որ միաժամանակ տեղի ունեցավ մի միտում՝ ծրագրային տրամաբանության տեղափոխմանը հաճախորդից կենտրոնական կետ, որը ներկայացնում է web ծրագիր, որի համար անհրաժեշտ է միայն ամենահեշտ հաճախորդ, ինտերնետ և դիտարկիչ:
Ու մենք հայտնվեցի ոչ թե պարզապես այնտեղ, որտեղ սկսեցինք՝ զրոյական հաճախորդներից և կենտրոնական սերվերներից: Մենք այնտեղ հասանք մի քանի անկախ ճանապարհներով:

Երևույթային սեղանի ենթակառուցվածք
Բրոքեր
2007 թվականին արդյունաբերական виртуալացման շուկայում առաջատարը՝ VMware-ը, թողարկել է իր VDM (Virtual Desktop Manager) արտադրանքի առաջին տարբերակը, որը փաստացիորեն առաջինն էր նոր հայտնվող վիրտուալ սեղանների շուկայում: Անգամ սպասելը երկար չտևեց և 2008 թվականին XenSource-ի ձեռքբերմամբ թողարկվեց XenDesktop-ը: Անկասկած, այլ վաճառողներ ևս ունեին իրենց առաջարկները, բայց չենք անդրադառնա պատմությանը, հեռանալով կոնցեպցիայից:
Եվ մինչ այսօր կոնցեպցիան պահպանվում է: VDI-ի հիմնական բաղադրիչը բրոքերն է:
Սա է վիրտուալ սեղանների ենթակառուցվածքի սիրտը:
Բրոքերը պատասխանատու է VDI-ի աշխատանքի ամենակարևոր գործընթացների համար:
- Որոշում է միացած հաճախորդին հասանելի ռեսուրսները (մեքենաներ/սեսիաներ);
- Բալանսավորում է անհրաժեշտության դեպքում հաճախորդներին մեքենաների/սեսիաների խմբերում;
- Հաճախորդին ուղղորդում է ընտրված ռեսուրսի վրա:
Այսօր VDI-ի համար հաճախորդը (տերմինալը) փաստորեն կարող է լինել ամեն ինչ, ինչի վրա կա էկրանը՝ նոթբուք, սմարթֆոն, պլանշետ, կիոսկ, նուրբ կամ զրոյական հաճախորդ: Իսկ պատասխանային մասը, որը իրականացնում է արտադրողական բեռը՝ տերմինալային սերվերի սեսիան, ֆիզիկական մեքենա, վիրտուալ մեքենա: Moderne հասուն VDI արտադրանքը մոտակա ինտեգրված է վիրտուալ ենթակառուցվածքի հետ և ինքնուրույն կառավարում է այն ավտոմատ ռեժիմում՝ տեղադրելով կամ հակառակը, հեռացնելով արդեն անհրաժեշտ չէին վիրտուալ մեքենաներ:
Թեթև մի քանի կողմ, բայց որոշ հաճախորդների համար VDI-ի համար ծայրահեղ կարևոր տեխնոլոգիան 3D գրադարանների ձեռնտու աշխատանքի աջակցությունն է նախագծողների կամ դիզայներների համար:
Պրոտոկոլ
Ventana VDI դյուրին լուծման երկրորդ ծայրահեղ կարևոր բաղադրիչը վիրտուալ ռեսուրսներին մուտքի պրոտոկոլն է: Եթե շահույթում խոսքը գնում է աշխատանքային տարածքում, որտեղ գոյություն ունի հիանալի վստահելի 1 Gbps դիմավորող ցանց և 1 ms ուշացումով, ապա կարելի է վերցնել փաստացիապես ցանկացած:
Բայց պետք է մտածել, երբ կապը գնում է վերահսկելի ցանցի միջոցով, և այդ ցանցի որակը կարող է լինել իռացիոնալ, մինչև տասնյակ կիլոբիտ արագություններ և կանխատեսվող ուշացումներով: Դա իրական տանից և օդանավակայաններից, սննդի ստանդարտներից աշխատանք կազմակերպելու համար:
Տերմինալային սերվերներ ընդդեմ հաճախորդային VM-ներ
VDI-ի հայտնվելուց հետո կարծես, թե ժամանակն է հրաժարվելու տերմինալային սերվերից: Ինչո՞ւ նրանց պետք են, եթե յուրաքանչյուրն ունի իր անձնական VM-ը:
Բայց մաքուր տնտեսագիտական տեսանկյունից պարզվեց, որ ֆիքսված զանգվածային աշխատանքային տեղերի համար, որոնք հոգնածության չափով նույնն են, առայժմ մեկ այլ բան չկա ավելի արդյունավետ, քան տերմինալային սերվերների գինը / նստաշրջանը: Չնայած իրենց բոլոր առավելություններին, "1 օգտատեր = 1 VM" մոտեցումը զգալիորեն ավելի շատ ռեսուրսներ է ծախսում виртуալ սարքավորումների ու լիարժեք օպերացիոն համակարգի վրա, ինչը վատացնում է տնտեսությունը սովորական աշխատանքային տեղերում.
Ի դեպ, բարձրագույն ղեկավարների, ոչ ստանդարտ և ծանրաբեռնված աշխատանքային տեղերի, բարձր իրավունքների (մինչև ադմինիստրատոր) անհրաժեշտության դեպքում, նախընտրելի է յուրաքանչյուր օգտվողի համար առանձին յուղված VM: Այս VM-ի շրջանակներում կարելի է առանձնացնել ռեսուրսները անհատականորեն, տրամադրել ցանկացած մակարդակի իրավունքներ և սահուն անցնել VM-ները վիրտուալիզացման հոստինգի միջև բարձր ծանրաբեռնման դեպքում.
VDI և տնտեսություն
Տարիներ շարունակ լսում եմ նույն հարցը՝ ինչպես, VDI-ն ավելի էժան չէ, քան պարզապես բոլորին նոութբուքներ տալը? Եվ տարիներ շարունակ ստիպված եմ պատասխանել նույնը: Պարզ գրասենյակային աշխատողների դեպքում VDI-ն ավելի էժան չէ, եթե հաշվենք սարքավորումների մաքուր ծախսերը: Ինչ էլ լինի, նոութբուքները էժանանում են, իսկ սերվերները, STB և համակարգային ծրագրերը բավական չափելի գումար են արժեցնում: Եթե ժամանակն է նորացնել սարքավորումների պարկը և մտածում եք VDI-ով տնտեսել, լինեք վստահ, որ չեն տնտեսվի.
Այսինքն, ես նշեցի սարսափելի երեք տառ GRC-ն՝ բայց VDI-ն դեռ GRC-ի մասին է: Սա ռիսկերի կառավարումը, մուտքի վերահսկողության և անվտանգության մասին է: Եվ սա սովորաբար պահանջում է զգալի ներդրում բազմազան սարքավորումների ներդրման համար: VDI-ի միջոցով վերահսկողության գործընթացը պարզեցվում է, անվտանգությունը բարձրանում է, իսկ մազերը դառնում են մաքուր և մետաղական.
HPE-ի լուծումները հեռավոր աշխատանքի համար
Հեռավոր և ամպային կառավարում
iLO
HPE ընկերությունը հեռավոր սերվերային ենթակառուցվածքի կառավարումի ասպարեզում վաղուց նորեկ չէ, եւ ընդհանրապես, մարտին տոնվեց iLO-ի (Integrated Lights Out) լեգենդար 18-ամյակը: 00-ականների վարչության ժամանակներից հիշելով, անձամբ չէի կարող բաց թողնել: Նախնական տեղադրման և մալուխների միացում — ահա, ինչ պետք է անես աղմկոտ և ցուրտ տվյալների կենտրոնում: Բոլոր մնացած կազմաձևումները, ներառյալ օպերացիոն համակարգի օգտագործումը, կարելի էր անել աշխատատեղից, երկու մոնիտորից և տաք սուրճի բաժակից: Եվ սա 13 տարի առաջ էր!

Այսօր HPE սերվերները պատահական չեն դարձել տարեցտարի հաստատուն որակի ստանդարտ, և ոչ վերջին դերը խաղում է հեռավոր կառավարման համակարգի ոսկե ստանդարտը՝ iLO.

Հատուկ ուզում եմ նշել HPE-ի գործողությունները կորոնավիրուսի նկատմամբ մարդկության վերահսկողությունը պահպանելու համար. , որ 2020 թվականի վերջը (ամենաքիչը) iLO Advanced լիցենզիան բոլորին մատչելի է անվճար.
Infosight
Եթե ձեր ենթակառուցվածքում ավելի քան 10 սերվեր կա, եւ համակարգավարը չտանջվում է boredom-ով, ապա, իհարկե, իսկապես լավ լրացում ստանդարտ մոնիթորինգի միջոցներին կլինի արհեստական բանականության հիմնված HPE Infosight ամպային համակարգը: Համակարգը ոչ միայն մոնիթորինգ է անում վիճակի ու կառուցում գծապատկերներ, այլ նաեւ ինքնուրույն խորհուրդ է տալիս հետագա գործողություններ՝ հիմնված ներկայիս իրավիճակի ու միտումների վրա:


Բացի, , փորձիր Infosight-ը:
OneView
Վերջում, բայց ոչ ըստ նշանակության, ցանկանում եմ նշել HPE OneView-ը՝ ամբողջ պրոդուկտային պորտֆելը` մեծ հնարավորություններով ենթակառուցվածքի ամբողջ մոնիթորինգի եւ կառավարման համար: Եվ այս ամենը առանց աշխատասեղանի հետեւից վեր կենալու, որն արտադրված կերպով կարող է ներկայիս վիճակում լինել ընդհանուր բնակավայրում:

SСD-ները նույնպես ոչ պակաս կարևոր են:
Իհարկե, բոլոր SСD-ները հեռակա կառավարվում են, մոնիթորինգ են իրականացվում՝ ինչպես դա եղել է նախկինում: Ուստի, այսօր ցանկանում եմ խոսել մեկ այլ բան, այն է՝ մեթրոկլաստերների մասին:
Մետրոկլաստերները շուկայում բավականին նոր չեն, բայց հենց դա է պատճառը, որ դրանք դեռ այնքան էլ տարածված չեն՝ մտածման իներտությունը եւ առաջին տպավորությունները իրենց ազդեցությունը ունեն: Իհարկե, 10 տարի առաջ նրանք արդեն եղան, բայց միանշանակ գնեցին սոսինձի կամ ահագին թանկ ոստիկանական գծից: Այդ տարիների ընթացքում, երբ մեթրոկլաստերների առաջին նախագծերը գրանցվեցին, փոխեցին արդյունաբերությունը եւ տեխնոլոգիայի հասանելիությունը լայն հանրությանը:
Ես հիշում եմ նախագծեր, որտեղ հատուկ բաժանում էին SСD-ի մասերը՝ առանձին` չափազանց կրիտիկական ծառայությունների համար մեթրոկլաստերում, առանձին` համաժամանակյա կրկնօրինակման (եղել է զգալիորեն ավելի խիստ):
Իրականում, 2020 թվականին մեթրոկլաստերը ձեզ չի արժե ոչինչ, եթե դուք ունեք երկու տարածք եւ չանապարհակներ կազմակերպելու կարողություն: Թեեւ միայն նույնպիսի ազդանշանները, որոնք անհրաժեշտ են սինխրոն կրկնօրինակումների համար, նույնն են, ինչ մեթրոկլաստերների համար: Ծրագրային ապահովումի լիցենզավորումը վաղուց արդեն սպասումների մեջ է՝ եւ սինխրոն կրկնօրինակը, երբեք_package-ով, գալիս է մեթրոկլաստերի հետ, իսկ միակ բանը, որը մինչ այժմ պահում է մեկ ուղղությամբ կրկնօրինակումը, դա կոնկրետ L2 ցանցի ձևավորումն է: Եվ դա էլ, L2 over L3 լիարժեքորեն արդեն քայլում է երկիր:

Եղած է ի՞նչ սկզբունքային տարբերություն սինխրոն կրկնօրինակման եւ մեթրոկլաստերի միջեւ հեռակա աշխատանքի տեսանկյունից:
Բոլորը շատ պարզ են: Մեթրոկլաստերը աշխատում է ինքնուրույն, ավտոմատ կերպով, միշտ, գրեթե ակնթարթորեն:
Ինչպես է երևում սինխրոն կրկնօրինակման ինքնակատարածությունը առնվազն մի քանի հարյուր VM ենթակառուցվածքում:
- Սիգնալը մտնում է аварիայից:
- Դեժուրային հերթը վերլուծում է իրավիճակը՝ կարելի է վստահաբար հաշվել 10-ից մինչեւ 30 րոպե միայն ազդանշան ստանալու եւ որոշման ընդունման համար:
- Երբ դեժուրային ինժեների լիազորություններ չկան ինքնուրույն անջատելու համար՝ դեռ վստահաբար 30 րոպե կապի համար անձի հետ, ով ունի լիազորություններ, եւ ձևական հաստատում անջատման սկսելու:
- Մեծ կարմիր կոճակի սեղմում.
- 10-15 րոպե ժամկետների և ծավալների վերափոխման, VM-ների նորից գրանցման համար:
- IP հասցեի փոփոխման համար 30 րոպե — անուշատես գնահատում:
- Եվ վերջապես VM-ների մեկնարկ և արտադրական ծառայությունների գործարկում:
Արդյունքում RTO (բիզնես գործընթացների վերականգնման ժամկետ) կարելի է ազատորեն գնահատել 4 ժամ:
Համեմատենք մետրոկլաստերի իրավիճակի հետ:
- ԱԹԿ-ն հասկանում է, որ կապը մետրոկլաստերի կրծքի հետ կորել է՝ 15-30 վայրկյան:
- Վիրուսավորման հոստերը հասկանում են, որ առաջին ԴՏԿ-ն կորել է՝ 15-30 վայրկյան (այդ պահին 1-ին պոյում):
- Ավտոմատ վերագործարկում 2-րդ ԴՏԿ-ում ½-ից մինչև ⅓ VM-ների՝ 10-15 րոպե մինչ ծառայությունների բարձրացումը:
- Խնդիրն է, որ տվյալ ժամանակահատվածում հերթապահ հերթափոխն հասկանում է, թե ինչ է տեղի ունեցել:
Արդյունքում՝ RTO = 0 որոշակի ծառայությունների համար, 10-15 րոպե ընդհանուր դեպքում:
Ինչու՞ միայն ½-ից մինչև ⅓ VM-ների վերագործարկում: Տեսեք ինչ կա այս հարցում:
- Դուք ամեն ինչ անում եք համախմբված, և ընդգրկում եք VM-ների ավտոմատ բալանսավորում: Արդյունքում՝ միջինում միայն ½ VM-ները գործում են մեկ ԴՏԿ-ում: Ավելին, մետրոկլաստերի իմաստն է կանգառները նվազեցնելու մեջ, հետևաբար ձեր շահերից է, որ կրճատեք նաև լարում ունեցող VM-ների թիվը:
- Առանձին ծառայությունները կարելի է դասակարգել ծրագրային մակարդակում, տարանջատելով տարբեր VM-ների մեջ: Դրա արդյունքում այդ զույգ VM-ները միատեղվում են, կամ կպցվում են տարբեր ԴՏԿ-ների, որպեսզի ծառայությունը չսպասի VM-ների վերագործարկմանը խափանումների դեպքում:
Գործունեության լավ կառուցված համակարգի դեպքում՝ որպես լայն մետրոկլաստերներով, բիզնեսի օգտագործողները աշխատում են նվազագույն ուշացումներով որևէ կետից, նույնիսկ ԴՏԿ-ի մակարդակում խափանումների դեպքում: Վատագույն դեպքում, ուշացումը կլինի մեկ բաժակ սուրճի ժամանակը:
Եվ natürlich, մետրոկլաստերները իդեալական աշխատում են ինչպես Valinor HPE 3Par-ում, այնպես էլ նոր Primera-ներում:

Հեռավոր աշխատանքային հարթակների կառուցվածքը
Տերմինալային սերվերներ
Թերմինալային սերվերների համար նորություն մտածելու անհրաժեշտություն չկա, HPE-ն արդեն տարիներ է, ինչ առաջարկում է աշխարհում լավագույն սերվերներից մեկը: Ապառիկ դասական՝ DL360 (1U) կամ DL380 (2U) կամ AMD-ի սիրահարների համար՝ DL385: Դ tentu կա նաև բլեյդ սերվերներ, ինչպես դասական C7000, այնպես էլ նոր կառուցվող Synergy պլատֆորմա:

Յուրաքանչյուր ոգով, յուրաքանչյուր գույնով, առավելագույն նստաշրջաններ սերվերներին:
«Դասական» VDI + HPE Simplivity
Այս առումով «դասական VDI» ասելով իմ ենթադրությունն է 1 օգտագործող = 1 VM հաճախորդային Windows-ով: Եվ իհարկե, չկա ավելի մոտ և հարազատ VDI բեռ hyper-converged համակարգերի համար, առավել ևս՝ դեդուպլիկացիա և կոմպրեսիա ունենալով:

Այստեղ HPE-ն կարող է առաջարկել ինչպես սեփական hyper-converged Simplivity պլատֆորմ, այնպես էլ սերվերներ / հավաստագրված միավորներ գործընկերների լուծումների համար, ինչպես օրինակ՝ VSAN Ready Nodes VDI կառուցելու համար VMware VSAN ենթակառուցվածքում:
ՆLet's talk a bit more about the Simplivity solution. As its name gently hints, simplicity (the English word 'simple' means simple) is the core aspect. Simplified deployment, simplified management, simplified scaling.
Hyper-converged systems are currently one of the hottest topics in IT, with around 40 vendors of varying levels. According to Gartner's magic quadrant, HPE is in the global top 5 and is positioned in the leaders' quadrant — they understand where the industry is heading and are able to materialize that understanding in hardware.
Architecturally, Simplivity is a classic hyper-converged system with controller virtual machines, meaning it can support various hypervisors, unlike integrated hypervisor systems. Indeed, as of April 2020, VMware vSphere and Microsoft Hyper-V are supported, with plans for KVM support announced. A key feature of Simplivity since its market introduction has been hardware-accelerated compression and deduplication using a specialized accelerator card.

It’s important to note that compression with deduplication is global and always on, meaning it’s not an optional feature but part of the solution’s architecture.

HPE is somewhat misleading when claiming 100:1 efficiency calculated in a particular way, but the utilization efficiency is indeed very high. The figure 100:1 just sounds too attractive. Let's examine how Simplivity is technically implemented to support such numbers.
Snapshot. Snapshots are 100% correctly implemented as RoW (Redirect-on-Write), and thus occur instantly without a performance penalty. This differentiates them from some other systems. Why do we need local snapshots without penalties? It's quite simple — to reduce RPO from 24 hours (average RPO for backups) to mere minutes or even seconds.
Backup. A snapshot differs from a backup only in how it is perceived by the virtual machine management system. If deleting a machine also removes everything else, it means it was a snapshot. If something remains, it means it's a backup. Thus, any snapshot can be considered a full backup if it is marked as such in the system and not deleted.
Իհարկե, շատերը կարող են հակառակվել՝ ինչպիսի՞ բեքափ է դա, եթե նա նույն համակարգում է պահպանվում: Իսկ այստեղ մի շատ պարզ պատասխան կա՝ հանդիպող հարցի տեսքով: Ասեք, արդյո՞ք դուք ունեք որպես ձևակերպված սպառումների մոդել, որը սահմանում է բեքափի պահպանման կանոնները: Դա լիարժեք և արդարացի բեքափ է ֆայլի մաքրման դեմ VM-ի ներսում, բեքափ է VM-ի ինքնին հեռացվելու դեմ: Եթե անհրաժեշտ է պահպանել բեքափը բացառապես առանձին համակարգում, դուք ունեք թեկնածություն՝ այդ սնայպոթի կրկնօրինակումը Simplivity-ի երկրորդ կլաստեր կամ HPE StoreOnce:

Եվ հենց այստեղ պարզ է, որ նման շրջանաձևությունը պարզապես իդեալական է ցանկացած տեսակի VDI-ի համար: Հետեւաբար, VDI-ը՝ դա հարյուրներ կամ նույնիսկ հազարներ մեկանման մեքենաներ են, որոնց մեկ OS է, նշված նույն ծրագրերով: Ամբողջական դեդուգլիկացիան ամենը կփոշիան և կրճատի նույնիսկ 100:1, այլ առավել լավ: 1000 VM-ն մեկ տպիչից մեկնաբանել՝ դա իրականում խնդիր չէ, այս մեքենաները ավելի երկար կագրանցվեն vCenter-ում, քան կլոնավորվեն:
Հատուկ բարեփոխվող լուծումների պահանջող օգտատերերի համար, ու նաև նրանց, ովքեր պետք են 3D արագացուցիչներ, ստեղծվել է Simplivity G շարքը:

Այս շարքում չի օգտագործվում լրակարկային արագացնող, ուստի նվազեցվել է կրագի քանակը, որպեսզի վերահսկիչը կարողանա վերահսկել ծրագրային միջոցով: Սա թույլ է տալիս ազատել PCIe սլոտներ ցանկացած այլ արագացուցիչների համար: Նույնպես խտացվել է հասանելի հիշողության ծավալը մինչեւ 3TB ամենաաղմկալի բեռների համար:

Simplivity-ը իդեալական է աշխարհագրորեն տարածված VDI ենթակառուցվածքների կազմակերպման համար, տվյալների կրկնօրինակմամբ կենտրոնական տվյալների կենտրոնում:

Այնպիսի VDI կառուցվածքը (և որպես այդպիսին, ոչ միայն VDI) հատկապես հետաքրքիր է ռուսական իրականություններին՝ մեծ հեռավորություններով (և հետևաբար ուշացումներ) և շատ հեռու հասանելի չկատարելու կապերով: Ստեղծվում են տարածաշրջանային կենտրոններ (և նույնիսկ պարզապես 1-2 Simplivity հանգույցներ շատ հեռավոր գրասենյակներում), որտեղ տեղական օգտատերերը կկարողանան արագ կապի միջոցով համագործակցել, պահպանվում է ամբողջական վերահսկողություն և կառավարում կենտրոնից, իսկ կենտրոնում կրկնօրինակվում է միայն փոքր քանակություն իսկական, արժեքավոր, այլ ոչ թե անպետք տվյալներ:
Իհարկե, Simplivity-ը ամբողջությամբ միացված է OneView-ի և InfoSight-ի:
Բարակ և զրո հաճախորդներ
Բարակ հաճախորդները՝ հատուկ լուծումներ, որոնք նախատեսված են բացառապես որպես տերմինալներ: Քանի որ հաճախորդը իրականում չի բեռնում բացի կապի պահպանման և տեսանյութի բացատրության գործերից՝ գրեթե միշտ մատակարարվում է առկայոց ադրբեջանական պրոցեսոր, փոքր բեռնման սկավառակ միայն հատուկ ներմուծվող OS-ի մեկնարկման համար, կարճ ասած, և վերջ: Դրանք իսկապես դժվար չէ վնասել, իսկ գողանալը անհնար է: Գինը փոքր է և տվյալներ չեն պահպանվում:
Post существует քաղաքային հատուկ կարգի թ dün clients, так называемые нулевые клиенты. Իրենց հիմնական տարբերությունը тонким клиентներից состоит в отсутствии անգամ встроенной օпераnungs systrainer, и նրանք աշխատում են բացառապես microchip-ի прошивкой. Зачастую в них ставляют специальные аппаратные ускорители видеопотока для терминальных протоколների, таких как PCoIP или HDX.
Несмотря на разделение большого “Хьюлетт Паккард” на отдельные HPE и HP, нельзя не упомянуть тонкие клиенты производства HP.
Выбор լայն ծավալի, на любой вкус и потребности — вплоть до многомониторных рабочих мест с аппаратным ускорением видеопотока.

Сервис HPE для вашей удаленной работы
И последним по списку, но не по значению, хочу упомянуть сервис HPE. Было бы слишком долго перечислять все уровни сервиса HPE и его возможности, но как минимум есть одно крайне важное предложение в условиях удаленной работы. А именно — сервисный инженер от HPE/авторизованного сервис-центра. Вы продолжаете работать удаленно, с любимой дачи, слушая шмелей, пока пчелка от HPE, приехав в датацентр, заменяет в ваших серверах диски или вышедший из строя блок питания.
HPE CallHome
В условиях сегодняшего дня, при ограничении передвижений, как никогда актуальной становится функция Call Home. Любая система HPE с данной функцией может самостоятельно сообщить об аппаратном или программном сбое в центр поддержки HPE. И вполне вероятно, деталь на замену и/или сервисный инженер к вам прибудет еще задолго до того, как вы заметите неполадки и проблемы с продуктивными сервисами.
Лично я функцию эту включать настоятельно рекомендую.
Ընտանիք: habr.com
