Серверлерди стеллаждар боюнча бөлүштүрүүнү оптималдаштыруу

Чаттардын биринде мага суроо берилди:

— Серверлерди стеллаждарга кантип туура таңуу керектиги жөнүндө окуй турган бир нерсе барбы?

Мен мындай текстти билбегенимди түшүндүм, ошондуктан өзүмдү жаздым.

Биринчиден, бул текст физикалык маалымат борборлорундагы (DCs) физикалык серверлер жөнүндө. Экинчиден, биз серверлер абдан көп деп эсептейбиз: жүздөгөн-миң азыраак сан үчүн бул тексттин мааниси жок. Үчүнчүдөн, бизде үч чектөө бар деп эсептейбиз: стеллаждардагы физикалык мейкиндик, ар бир стойкага электр менен камсыздоо жана стеллаждар катарга турушу үчүн, биз чектеш стеллаждардагы серверлерди туташтыруу үчүн бир ToR которуштурууну колдоно алабыз.

Суроонун жообу биз кайсы параметрди оптималдаштырып жатканыбыздан жана эң жакшы натыйжага жетүү үчүн эмнени өзгөртө аларыбыздан көз каранды. Мисалы, андан аркы өсүш үчүн көбүрөөк калтыруу үчүн биз эң аз орунду ээлешибиз керек. Же, балким, биз стеллаждардын бийиктигин, ар бир стойкага кубаттуулукту, PDUдагы розеткаларды, өчүргүчтөр тобундагы стеллаждардын санын (1, 2 же 3 стеллаждар үчүн бир өчүргүч), зымдардын узундугун жана тартуу ишин тандоодо эркиндикке ээ болушубуз мүмкүн. бул катарлардын аягында абдан маанилүү: катарда 10 стеллаж жана ар бир коммутатордо 3 стеллаж менен зымдарды башка сапка тартууга же коммутатордогу портторду жетишсиз колдонууга туура келет) ж.б.у.с. Өзүнчө окуялар: серверлерди тандоо жана DC тандоо, биз алар тандалган деп ойлойбуз.

Кээ бир нюанстарды жана майда-чүйдөлөрдү, атап айтканда, серверлердин орточо/максималдуу керектөөсүн жана электр энергиясы бизге кандайча берилип жатканын түшүнсө жакшы болмок. Ошентип, бизде 230V жана бир стойкага бир фазадан турган орусиялык электр энергиясы бар болсо, анда 32А машина ~ 7кВт көтөрө алат. Бир стойкага номиналдуу түрдө 6 кВт төлөйбүз дейли. Эгерде провайдер биздин керектөөнү ар бир стойка үчүн эмес, 10 стойка үчүн гана өлчөсө жана эгер машина шарттуу түрдө 7 кВт үзгүлтүккө орнотулган болсо, анда техникалык жактан биз бир стеллажда 6.9 кВт, башкада 5.1 кВт керектей алабыз. баары жакшы болот - жазаланбайт.

Адатта биздин негизги максатыбыз чыгымдарды азайтуу болуп саналат. Өлчөөнүн эң жакшы критерийи болуп ТКОнун (менчиктин жалпы наркы) төмөндөшү саналат. Ал төмөнкү бөлүктөрдөн турат:

  • CAPEX: DC инфраструктурасын, серверлерди, тармактык жабдыктарды жана кабелдерди сатып алуу
  • OPEX: DC ижарасы, электр энергиясын керектөө, тейлөө. OPEX кызмат мөөнөтүнөн көз каранды. Аны 3 жыл деп эсептөө жөндүү.

Серверлерди стеллаждар боюнча бөлүштүрүүнү оптималдаштыруу

Жеке кесимдердин жалпы пирогдо канчалык чоң экендигине жараша, биз эң кымбатын оптималдаштырышыбыз керек, ал эми калганына калган ресурстардын бардыгын мүмкүн болушунча үнөмдүү колдонушубуз керек.

Келгиле, бизде учурдагы DC бар дейли, H бирдиктеринин регинин бийиктиги бар (мисалы, H=47), бир стойкадагы электр энергиясы Prack (Prack=6kW) жана биз h=2U эки бирдик серверлерин колдонууну чечтик. Биз өчүргүчтөр, патч панелдер жана уюштуруучулар үчүн стеллаждан 2..4 бирдикти алып салабыз. Ошол. физикалык жактан алганда, биздин стеллажда Sh=rounddown((H-2..4)/h) серверлер бар (б.а. Sh = rounddown((47-4)/2)=ар бир стеллажда 21 сервер). Мына ушул Ш.

Жөнөкөй учурда, текчедеги бардык серверлер бирдей. Бардыгы болуп, стеллажды серверлер менен толтурсак, анда ар бир серверде орточо эсеп менен Pserv=Prack/Sh (Pserv = 6000W/21 = 287W) кубаттуулукту сарптай алабыз. Жөнөкөйлүк үчүн биз бул жерде коммутатор керектөөсүнө көңүл бурбайбыз.

Келгиле, бир кадам четке кагып, сервердин максималдуу керектөө Pmax кандай экенин аныктайлы. Эгерде бул абдан жөнөкөй, өтө натыйжасыз жана толугу менен коопсуз болсо, анда биз сервердин электр камсыздоосунда жазылгандарды окуйбуз - бул.

Эгер ал татаалыраак жана натыйжалуураак болсо, анда биз бардык компоненттердин TDP (жылуу дизайн пакетин) алып, аны жыйынтыктайбыз (бул анчалык деле туура эмес, бирок мүмкүн).

Көбүнчө биз компоненттердин TDPын билбейбиз (CPUдан башка), ошондуктан биз эң туура, бирок эң татаал мамилени (бизге лаборатория керек) колдонобуз - биз керектүү конфигурациянын эксперименталдык серверин алып, аны жүктөйбүз, мисалы, Linpack (CPU жана эс тутум) жана fio (диск) менен биз керектөөнү өлчөйбүз. Эгерде биз аны олуттуу кабыл алсак, тесттер учурунда муздак коридордо эң жылуу чөйрөнү түзүшүбүз керек, анткени бул желдеткичтин керектөөсүнө да, CPU керектөөсүнө да таасирин тийгизет. Биз ушул конкреттүү жүктөмдүн астында ушул спецификалык шарттарда белгилүү бир конфигурациялуу белгилүү сервердин максималдуу керектөөсүн алабыз. Биз жөн гана тутумдун жаңы микропрограммасы, башка программалык камсыздоо версиясы жана башка шарттар натыйжага таасир этиши мүмкүн дегенди билдиребиз.

Ошентип, кайра Pserv жана биз аны Pmax менен кантип салыштырабыз. Бул кызматтардын кантип иштээрин жана техникалык директоруңуздун нервдери канчалык күчтүү экенин түшүнүү маселеси.

Эгерде биз эч кандай тобокелчиликке барбасак, анда бардык серверлер бир эле учурда максималдуу колдоно башташат деп ишенебиз. Ошол эле учурда, DC бир киргизүү болушу мүмкүн. Бул шарттарда да, инфра кызмат көрсөтүүсү керек, ошондуктан Pserv ≡ Pmax. Бул ишенимдүүлүк абдан маанилүү болгон ыкма.

Эгерде технологиялык директор идеалдуу коопсуздук жөнүндө гана эмес, компаниянын акчасы жөнүндө да ойлонсо жана жетиштүү эр жүрөк болсо, анда сиз муну чече аласыз.

  • Биз өзүбүздүн сатуучуларды башкара баштайбыз, атап айтканда, биз бир киргизүүдөгү төмөндөөнү азайтуу үчүн пландаштырылган эң жогорку жүктөмдүн убагында пландуу тейлөөгө тыюу салабыз;
  • жана/же биздин архитектура стойка/катар/DC жоготууга мүмкүндүк берет, бирок кызматтар иштей берет;
  • жана/же биз жүктү стеллаждар боюнча туурасынан жакшылап таратабыз, андыктан биздин кызматтар эч качан бир стеллажда максималдуу керектөөгө секире албайт.

Бул жерде жөн гана божомолдоо эмес, керектөөнү көзөмөлдөө жана серверлер кадимки жана эң жогорку шарттарда электр энергиясын кантип керектелерин билүү үчүн абдан пайдалуу. Ошондуктан, бир нече анализден кийин, технологиялык директор колунда болгондун бардыгын кысып, мындай дейт: "Биз ыктыярдуу чечим кабыл алабыз: бир стойкага максималдуу сервер керектөөнүн максималдуу орточо баасы максималдуу керектөөдөн **ошончолук** төмөн" деп шарттуу түрдө Pserv = 0.8* Pmax.

Анан 6 кВттык стойкага Pmax = 16 Вт болгон 375 сервер эмес, Pserv = 20 Вт * 375 = 0.8 Вт болгон 300 сервер жайгаша албайт. Ошол. 25% көбүрөөк серверлер. Бул абдан чоң үнөмдөө - биз дароо эле 25% азыраак стеллаждарды талап кылабыз (жана биз PDU, өчүргүчтөр жана кабелдерди үнөмдөйбүз). Мындай чечимдин олуттуу кемчилиги - биздин божомолдорубуз дагы эле туура экенине дайыма көз салып турушубуз керек. Жаңы микропрограмма версиясы күйөрмандардын иштешин жана керектөөнү олуттуу өзгөртпөйт, жаңы релиз менен күтүлбөгөн жерден иштеп чыгуу серверлерди кыйла эффективдүү колдоно баштаган жок (окуңуз: алар серверде көбүрөөк жүктөмгө жана көбүрөөк керектөөлөргө жетишти). Анткени, ошондо биздин алгачкы божомолдорубуз да, корутундуларыбыз да дароо туура эмес болуп калат. Бул жоопкерчилик менен кабыл алынышы керек болгон тобокелдик (же болтурбоо жана андан кийин ачык колдонулбаган стеллаждар үчүн төлөө).

Маанилүү эскертүү - мүмкүн болсо, ар кандай кызматтардын серверлерин горизонталдуу түрдө стеллаждар боюнча бөлүштүрүүгө аракет кылышыңыз керек. Бул серверлердин бир партиясы бир кызматка келгенде, жагдайлар болбошу үчүн зарыл, стеллаждар аны менен "тыгыздыгын" жогорулатуу үчүн вертикалдуу жыйылган (анткени бул жеңилирээк). Чындыгында, бир стойкага ошол эле кызматтын бирдей аз жүктөм серверлери, ал эми экинчиси бирдей жүктөмдүү серверлер менен толтурулат экен. Экинчи түшүү ыктымалдыгы кыйла жогору, анткени жүк профили бирдей жана бул стеллаждагы бардык серверлер жүктүн жогорулашынын натыйжасында бирдей көлөмдө керектей башташат.

Серверлерди стеллаждарда бөлүштүрүүгө кайтып келели. Биз физикалык стойка мейкиндигин жана кубаттуулук чектөөлөрүн карап чыктык, эми тармакты карап көрөлү. Сиз 24/32/48 N порттору бар которгучтарды колдоно аласыз (мисалы, бизде 48 порттук ToR которгучтары бар). Бактыга жараша, эгер сиз үзүлүүчү кабелдер жөнүндө ойлонбосоңуз, көптөгөн варианттар жок. Rnet тобунда ар бир стойкага бир которгуч, эки же үч стеллаж үчүн бир которгуч болгондо сценарийлерди карап жатабыз. Менин оюмча, бир топко үчтөн ашык стеллаждар өтө эле көп окшойт, анткени... стеллаждардын ортосундагы кабель маселеси бир топ чоң болуп калат.

Ошентип, ар бир тармак сценарийи үчүн (топтогу 1, 2 же 3 стеллаждар) биз серверлерди стеллаждар арасында бөлүштүрөбүз:

Srack = мин(Sh, тегерек (Prack/Pserv), тегерек (N/Rnet))

Ошентип, бир топтун 2 стойкалары бар вариант үчүн:

Srack2 = мин(21, тегеректөө(6000/300), тегеректөө(48/2)) = мин(21, 20, 24) = ар бир стойкага 20 сервер.

Биз ошол эле жол менен калган параметрлерди карап көрөлү:

Srack1 = 20
Srack3 = 16

Ал эми биз дээрлик ошол жердебиз. Биз S бардык серверлерибизди жайылтуу үчүн стеллаждардын санын эсептейбиз (ал 1000 болсун):

R = roundup(S / (Srack * Rnet)) * Rnet

R1 = жалпылоо (1000 / (20 * 1)) * 1 = 50 * 1 = 50 стеллаждар

R2 = жалпылоо (1000 / (20 * 2)) * 2 = 25 * 2 = 50 стеллаждар

R3 = жалпылоо (1000 / (16 * 3)) * 3 = 25 * 2 = 63 стеллаждар

Андан кийин, биз стеллаждардын санына, керектүү сандагы өчүргүчтөрдүн, кабелдердин ж.б. негизинде ар бир вариант үчүн ТКОну эсептейбиз. Биз ТКО төмөн болгон вариантты тандайбыз. Profit!

1 жана 2 варианттары үчүн стеллаждардын талап кылынган саны бирдей болгонуна карабастан, алардын баасы ар кандай болот, анткени экинчи вариант үчүн өчүргүчтөрдүн саны жарым эсе көп, ал эми талап кылынган кабелдердин узундугу узунураак.

PS Эгерде сизде стойкага кубаттуулук жана стеллаждын бийиктиги менен ойноо мүмкүнчүлүгүңүз болсо, өзгөрмөлүүлүк көбөйөт. Бирок процессти жөн гана варианттарды карап чыгуу менен жогоруда сүрөттөлгөн процесске чейин кыскартса болот. Ооба, дагы көп айкалышуулар болот, бирок дагы эле өтө чектелген сан - эсептөө үчүн стойкага электр энергиясы 1 кВт кадамдар менен көбөйтүлүшү мүмкүн, типтүү стеллаждар чектелген сандагы стандарттуу өлчөмдөрдө болот: 42U, 45U, 47U, 48U , 52U. Ал эми бул жерде Excel'дин Data Table режиминдеги "Эгерде" анализи эсептөөлөргө жардам берет. Биз алынган плиталарды карап, минимумду тандайбыз.

Source: www.habr.com

Комментарий кошуу