Սերվեր գնելը դեռևս չի նշանակում տվյալների կենտրոն կառուցել։ Ամենաթանկ սխալները հենց այստեղ են սկսվում, երբ ընկերությունը ձեռք է բերում լավ սարքավորում, բայց չի հաշվարկել էներգամատակարարումը, հովացման համակարգը, ցանցի տոպոլոգիան, պահուստավորումը և ֆիզիկական տարածքը։ Տվյալների կենտրոնի կազմակերպման այս ուղեցույցը նախատեսված է այն բիզնեսների համար, որոնք ցանկանում են ենթակառուցվածքը կառուցել ոչ թե «ինչպես ստացվի», այլ՝ կայունության, ընդլայնման և արդյունավետ սպասարկման սկզբունքների հիման վրա։

Ե՞րբ է ընկերությանը անհրաժեշտ սեփական տվյալների կենտրոնը

Յուրաքանչյուր կազմակերպության անհրաժեշտ չէ լիարժեք տվյալների կենտրոն։ Որոշ դեպքերում բավարար է մեկ կամ երկու rack server, NAS և ճիշտ նախագծված UPS ենթակառուցվածք։ Սակայն եթե ընկերությունն ունի կրիտիկական բիզնես հավելվածներ, տեղային տվյալների պահպանման պահանջ, ցածր ուշացման (latency) անհրաժեշտություն, ներքին համակարգերի նկատմամբ լիարժեք վերահսկողության ցանկություն կամ համապատասխանության (compliance) հետ կապված սահմանափակումներ, ապա սեփական ենթակառուցվածքի ստեղծումն արդեն ոչ թե հարմարավետության, այլ գործառնական անհրաժեշտության հարց է։

Երկրորդ կարևոր գործոնը աճն է։ Փոքր գրասենյակի համար սկզբում կարող է բավարար լինել մեկ սերվերային պահարան, սակայն եթե 12-18 ամսվա ընթացքում նախատեսվում է նոր մասնաճյուղի բացում, օգտատերերի թվի աճ, ERP համակարգի, տեսաարխիվի կամ վիրտուալացված միջավայրի ընդլայնում, անհրաժեշտ է հենց սկզբից ընտրել այնպիսի ճարտարապետություն, որը ապագայում չի պահանջի ամբողջական վերակառուցում։

Տվյալների կենտրոնի կազմակերպման ուղեցույց — պլանավորումը սկսվում է ծանրաբեռնվածությունից

Առաջին հարցը պարզ է․ ինչի՞ համար պետք է ծառայի ենթակառուցվածքը։ Եթե այս հարցի պատասխանը հստակ չէ, հետագա գնումները նույնպես կլինեն պատահական։ Նախ պետք է սահմանել աշխատանքային ծանրաբեռնվածությունները (workloads)՝ վիրտուալ մեքենաներ, ֆայլային պահոց, պահուստային համակարգ, տեսախցիկների արխիվ, տվյալների բազաներ, ERP, դոմենային ծառայություններ, էլեկտրոնային փոստի ենթակառուցվածք կամ հատուկ հավելվածներ։

Դրանից բխում են երեք հիմնական պարամետրեր՝ հաշվարկային ռեսուրսներ, պահեստային տարածք և ցանցային թողունակություն։ Օրինակ՝ եթե միջավայրը հիմնականում նախատեսված է ֆայլերի և պահուստային պատճենների համար, ուշադրությունը կկենտրոնանա storage capacity-ի (պահեստի ծավալի) և սկավառակների զանգվածի տեսակի վրա։ Եթե գործ ունենք վիրտուալացման և տվյալների բազաների հետ, ավելի կարևոր են CPU core density-ը (պրոցեսորի միջուկների խտությունը), RAM-ի ծավալը և ցածր latency ունեցող storage-ը։

Լավ փորձ է կատարել առնվազն 3 տարվա կանխատեսում։ Ոչ թե իդեալական ճշգրտությամբ, այլ մոտավոր աշխատանքային միջակայքով՝ քանի օգտատեր կավելանա, քանի համակարգ կտեղափոխվի on-prem միջավայր և ինչպես կաճի պահեստի ծավալը տարեկան կտրվածքով։ Տվյալների կենտրոնը չի նախագծվում միայն այսօրվա ծանրաբեռնվածության համար։

Տարածք և rack ենթակառուցվածք

Հաճախ անտեսվող հարց է հենց սենյակը։ Տվյալների կենտրոնի համար նախատեսված տարածքը պետք է լինի վերահսկվող, սահմանափակ հասանելիությամբ, կայուն էլեկտրական միջավայրով և համապատասխան օդափոխությամբ։ Եթե ենթակառուցվածքը փոքր է, հնարավոր է բավարար լինի առանձին server room-ը։ Սակայն նույնիսկ այդ դեպքում սենյակը չպետք է միաժամանակ ծառայի որպես պահեստ, գրասենյակ և սերվերային տարածք։

Rack-ի (սերվերային պահարանի) ընտրությունը կատարվում է ոչ միայն բարձրությամբ, այլև խորությամբ, ծանրաբեռնվածության հնարավորությամբ, մալուխների կառավարմամբ և օդի հոսքի կազմակերպմամբ։ Enterprise դասի սերվերների համար ոչ բավարար խորությամբ պահարանը հաճախ խնդիր է դառնում։ Անհրաժեշտ է նաև նախապես նախատեսել PDU-ների (էլեկտրաբաշխիչների), patch panel-ների, switch-երի տեղադրումը, UPS-ի միացումները և մալուխային ուղիները։

Եթե այսօր անհրաժեշտ է 12U, հաճախ 18U ընտրելը ավելի շահավետ է, քան մեկ տարի անց ամբողջ համակարգը նոր պահարան տեղափոխելը։ Rack capacity-ի պլանավորման ժամանակ ազատ տարածքը շքեղություն չէ՝ այն սպասարկման և ապագա ընդլայնման ռեսուրս է։

Էներգամատակարարում — մեկ կետի խափանումը ամենաթանկն է

Էլեկտրաէներգիան տվյալների կենտրոնի հիմքն է։ Եթե այստեղ սխալ թույլ տաք, մնացած բաղադրիչների որակը քիչ բան կօգնի։ Պլանավորման ժամանակ անհրաժեշտ է որոշել ընդհանուր ծանրաբեռնվածությունը վատտերով (W), առավելագույն սպառումը, գործարկման (start-up) ծանրաբեռնվածությունը և պահուստային տոկոսը։ Շատ ընկերություններ UPS-ն ընտրում են միայն անվանական հզորությամբ, սակայն չեն հաշվում իրական ինքնավարության ժամանակը, power factor-ը (հզորության գործակիցը) և ընդլայնման հնարավորությունը։

UPS ենթակառուցվածքի ընտրությունը կախված է անհրաժեշտ պաշտպանության տևողությունից։ Որոշ միջավայրերում բավարար է 5-10 րոպեն՝ գեներատորի միացման կամ համակարգերի ճիշտ անջատման համար։ Այլ դեպքերում պահանջվում է 20-30 րոպեից ավելի ինքնավարություն, քանի որ էլեկտրաէներգիայի ընդհատումները կարող են երկար տևել կամ գեներատոր հասանելի չլինել։ Այդ դեպքում անհրաժեշտ է ճիշտ հաշվարկել մարտկոցների բլոկը, ծանրաբեռնվածության պրոֆիլը և ապագա ընդլայնումը։

Այն միջավայրերում, որտեղ հավելվածների հասանելիությունը կրիտիկական է, ցանկալի է կիրառել A և B power feed (երկակի սնուցման գծեր) սկզբունքը։ Երկակի սնուցման բլոկ ունեցող սերվերները իրական օգուտ են տալիս միայն այն դեպքում, երբ դրանք միացված են անկախ էլեկտրական գծերին։ Հակառակ դեպքում redundancy-ն մնում է միայն թղթի վրա։

Հովացում — ջերմային ռեժիմը որոշում է հուսալիությունը

Հովացման հարցին հաճախ անդրադառնում են այն ժամանակ, երբ սենյակում արդեն շոգ է, իսկ սերվերների fan speed-ը աշխատում է առավելագույն ռեժիմով։ Սա ուշացած մոտեցում է։ Նախ պետք է հասկանալ, թե որքան ջերմություն է արտադրում IT load-ը, ինչ ծավալ ունի սենյակը, ինչպես է շարժվում օդը և ինչ է տեղի ունենում ամառային առավելագույն ջերմաստիճանների ժամանակ։

Փոքր սերվերային սենյակի համար երբեմն բավարար է dedicated precision cooling-ը (մասնագիտացված ճշգրիտ հովացում) կամ ճիշտ հաշվարկված օդորակման համակարգը, սակայն սովորական գրասենյակային օդորակիչը միշտ չէ, որ կարող է աշխատել 24/7 ռեժիմով։ Կարևոր է ոչ միայն ջերմաստիճանը, այլև օդի հոսքի ուղղությունը, hot spots-ի կանխումը և խոնավության վերահսկումը։

Եթե ունեք մի քանի պահարան, cold aisle/hot aisle (սառը և տաք միջանցքների) տրամաբանությունը դառնում է գործնական անհրաժեշտություն։ Նույնիսկ փոքր միջավայրում ճիշտ կազմակերպված airflow-ը զգալիորեն նվազեցնում է գերտաքացման վտանգը և էներգիայի ծախսը։

Ցանց — արագը միշտ չէ, որ նշանակում է ճիշտ պլանավորված

Տվյալների կենտրոնի ցանցի նախագծման ժամանակ սխալը հաճախ սկսվում է այն պահից, երբ բոլոր պորտերը պարզապես միացվում են «մեկ մեծ switch-ի»։ Իրականում անհրաժեշտ է դերերի բաժանում՝ management network, production traffic, storage traffic, backup traffic և անհրաժեշտության դեպքում DMZ սեգմենտ։ Սա բարելավում է ինչպես անվտանգությունը, այնպես էլ ախտորոշումը։

1GbE-ը դեռ բավարար է որոշ ծանրաբեռնվածությունների համար, սակայն վիրտուալացման կլաստերներում, ընդհանուր storage-ի օգտագործման կամ backup window-ի կրճատման դեպքում 10GbE-ը հաճախ դառնում է հիմնական պահանջ։ Ավելի բարձր արագությունը միշտ անհրաժեշտ չէ, սակայն uplink-ների թողունակությունը չպետք է դառնա սահմանափակող գործոն աճի առաջին փուլում։

Խորհուրդ է տրվում օգտագործել switch stack կամ redundant core այն միջավայրերում, որտեղ մեկ սարքի խափանումը կարող է կանգնեցնել բիզնեսը։ Անհրաժեշտ է նաև մալուխների հստակ նշագրում և patching-ի փաստաթղթավորում։ Վատ նշագրված պորտերը և անկանոն մալուխավորումը վթարի ժամանակ կարող են թանկարժեք ժամեր կորցնել։

Պահեստ և սերվերներ — ընտրությունը պետք է բխի ծանրաբեռնվածությունից

Սերվերի ընտրությունը սկսվում է ոչ թե բրենդից, այլ workload profile-ից։ Քանի վիրտուալ մեքենա ունեք, ինչ տեսակի CPU-bound կամ memory-bound գործընթացներ են աշխատում, ինչ IOPS պահանջ կա և ինչպիսի redundancy է անհրաժեշտ host մակարդակում։ Փոքր ընկերությունում երկու ճիշտ կազմավորված սերվեր և հիպերվայզորի կլաստերը հաճախ ավելի լավ լուծում են, քան մեկ «հզոր» սերվերը։

Storage-ի դեպքում հիմնական հարցերն են՝ capacity (ծավալ), performance (արտադրողականություն) և resilience (կայունություն)։ SATA, SAS և SSD/NVMe սկավառակների ընտրությունը պետք է հիմնված լինի իրական ծանրաբեռնվածության վրա։ Տեսաարխիվի և transactional database-ի պահանջները տարբեր են։ RAID մակարդակները, hot spare սկավառակները, controller redundancy-ն և snapshot/backup հնարավորությունները պետք է նախապես քննարկվեն։

NAS-ի և SAN-ի միջև ընտրությունը նույնպես կախված է իրավիճակից։ Եթե պահանջվում է կենտրոնացված ֆայլային պահոց և պահուստավորում, NAS-ը հաճախ ամենագործնական տարբերակն է։ Եթե խոսքը բարձր արտադրողականությամբ վիրտուալացված միջավայրի մասին է, SAN-ը կամ all-flash storage-ը կարող են լիովին արդարացված լինել, սակայն բյուջեն նույնպես զգալիորեն աճում է։

Անվտանգություն — ֆիզիկական և տրամաբանական վերահսկումը միասին են աշխատում

Տվյալների կենտրոնի անվտանգությունը չի սկսվում և չի ավարտվում firewall-ով։ Առաջին հերթին անհրաժեշտ է ֆիզիկական մուտքի վերահսկում՝ ով է մտնում սենյակ, ինչպես է դա գրանցվում, կա՞ տեսահսկում և միջավայրի վերահսկման սենսորներ։ Նույնիսկ փոքր բիզնեսում server room-ը չպետք է լինի բոլորի համար հասանելի տեխնիկական տարածք։

Տրամաբանական մակարդակում անհրաժեշտ են ցանցի սեգմենտավորում, ադմինիստրատիվ հասանելիությունների սահմանափակում, MFA (բազմագործոն նույնականացում), firmware-ի և համակարգային թարմացումների կանոնավոր գործընթաց, ինչպես նաև կենտրոնացված լոգավորում։ Շատ ընկերություններ ունեն պահուստային պատճեններ, սակայն դրանք պաշտպանված չեն ransomware ծրագրերից։ Offline կամ immutable backup ռազմավարությունը այսօր անհրաժեշտություն է ոչ միայն խոշոր կազմակերպությունների, այլ գրեթե բոլոր բիզնեսների համար։

Մոնիտորինգ, փաստաթղթավորում և սպասարկելիություն

Լավ կազմակերպված ենթակառուցվածքն այն է, որը նախապես ազդանշան է տալիս խնդիրների մասին։ Մոնիտորինգը պետք է ներառի էներգիան, ջերմաստիճանը, UPS-ի կարգավիճակը, սկավառակների վիճակը, ցանցային ինտերֆեյսները, սերվերների ռեսուրսները և կրիտիկական ծառայությունների հասանելիությունը։

Փաստաթղթավորումը նույնպես կարևոր է։ IP պլանը, rack layout-ը, պորտերի քարտեզը, պահուստավորման սխեման, լիցենզիաները, երաշխիքները և service tag-երը պետք է պահվեն մեկ վայրում։ Ենթակառուցվածքի կառավարումը չպետք է կախված լինի միայն մեկ անձից։

Բյուջե — որտեղ չարժե խնայել

Յուրաքանչյուր նախագիծ ունի ֆինանսական սահմանափակումներ, սակայն բոլոր բաղադրիչների վրա նույն կերպ խնայելը սխալ մոտեցում է։ Ամենաթանկ սխալները հաճախ կապված են UPS-ի, հովացման, որակյալ սկավառակների, redundant սնուցման և երաշխիքային պայմանների հետ։ Միևնույն ժամանակ միշտ անհրաժեշտ չէ գնել ամենաբարձր դասի սարքավորում, եթե ընթացիկ ծանրաբեռնվածությունը դա չի պահանջում։

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

Եթե նախագիծը սկսում եք զրոյից, առաջին քայլը սարքավորումների ամբողջական ցանկ կազմելը չէ։ Նախ պետք է հստակ սահմանել պահանջները, կրիտիկական ծառայությունները, աճի սցենարը և համակարգի անջատման ընդունելի առավելագույն սահմանը։ Դրանից հետո ճարտարապետությունը ավելի արագ և ճիշտ կնախագծվի, գնումներն ավելի քիչ մասնատված կլինեն, իսկ ստացված ենթակառուցվածքը կաշխատի այնպես, ինչպես պահանջում է բիզնեսը՝ ոչ միայն գործարկման օրը, այլ նաև հաջորդ տարիների ընթացքում։