Сервер бөлмесінде 10/25/100GbE-ге көшу қашан тиімді

Желінің тар нүктеге айналуы нені білдіреді

Желі тар нүкте болады, егер серверлер мен сақтау жүйесінде CPU, RAM және дискілер жеткілікті болса да, қолданбалар деректер тораптар арасында өтпей, баяу жұмыс істесе. Көбінесе бұл 100% тұрақты жүктеме ретінде емес, қысқа уақыттық шыңдар, коммутатордағы кезектер және кешігулердің өсуі арқылы байқалады.

Әдетте желіге көп сөйлейтін тапсырмалар ұрысады: виртуализация миграциялары мен сақтау, белсенді сұрауы бар дерекқорлар, VDI (әсіресе кіру уақытында), сондай-ақ бэкаптар мен репликация трафигі. 1GbE-де мұндай жүктемелер белгілі бір масштабқа дейін қанағаттанарлық болуы мүмкін, бірақ өсу (10–20 VM, қосымша узел, көп қолданушылар) жоғарыласа жағдай күрт нашарлайды.

Орташа жүктемені ғана қарау маңызды емес. Орташа 30–40% болуы мүмкін, бірақ микрошабуылдар кезінде пакеттер кезекке тұрып, жоғалыстар мен қайта жіберулер пайда болады. Қолданбалар мұны кешігулер мен «жабысулар» ретінде сезеді.

Көбінесе тарлық бірнеше жерде көрініс табады:

• стойкадағы ToR-коммутатор — көптеген серверлер бір немесе екі аплинкті бөліседі
• агрегацияға немесе ядроға аплинк, әсіресе бір уақытта бірнеше бэкап жүрсе
• сақтау желісі (iSCSI/NFS/CEPH) немесе оның болмауы, егер бәрі бір арнада араласса
• виртуализация кластеріндегі межузловой трафик (vMotion/Live Migration)

Егер 10/25/100GbE-ге көшу туралы әңгіме болса, алдымен: кешігулер қай жерде өсіп жатыр және қай жерде кезектер пайда болатынын анықтаңыз. Бұл есептеудің бастамасы болады және жай ғана жылдам порттарды сатып алып, әлі де бөтелке жоғын қалдырмауға көмектеседі (мәселен аплинкте немесе storage-желісінде).

Қай кезде порт жылдамдығын жоғарылату қажет

Ең жиі белгі — желі жұмыс істеп тұрған сияқты, бірақ маңызды операциялар айтарлықтай ұзағырақ уақыт алатын болды: файлдарды көшіру, ауыр құжаттарды ашу, түнгі бэкаптар, VDI-ге кіру. Егер серверлердегі CPU мен дискілер бос болса, желіні тексеру орынды.

Коммутаторлардың және серверлердің графиктерінен бастаңыз. Қауіпті тек 90–100% жүктеме емес, сонымен қатар порттағы кезектер, дроптар және қателер. Көп жағдайда тәуліктік орташа жүктеме аз көрініп тұрады, бірақ 10–15 минуттық шыңдар желіні тоқтатады және осы минуттарда сервис бұзылады. Сондықтан шыңдарды іс-шаралармен байланыстырыңыз: бэкаптар, репликация, жаңартулар, виртуалдық машиналардың миграциясы.

Виртуализация жағынан тарлық жанама белгілер арқылы көрінеді: VM миграциялары ұзарады, «түрткі» болатын бір көршінің әрекеті басқа VM-лардың жұмысын айтарлықтай нашарлатады. Бұл east-west трафиктің хосттар мен сақтау арасында порт жылдамдығына немесе стойка аплингіне тірелуін білдіруі мүмкін.

Сақтаудан көрінетін типтік белгі — latency өсіп кетеді, ал дискілер мен контроллерлер экстремалды жүктемеде емес. Мысалы, күндіз қолданушылар VDI-да кідірістерге шағымданады, ал мониторинг параллель тапсырмалар кезінде iSCSI/NFS задержкаларының өршуін көрсетеді.

Назар аудару керек метрикалар:

• жұмыс уақытында порттың жиі 100%-ға жақын шыңдары
• порттағы кезектер мен дроптар (айтарлықтай авариялар болмаса да)
• интерфейстегі CRC/қателер (көп жағдайда кабель/оптика проблемасын жасырады)
• бұрынғы көлемде бэкаптар мен репликациялардың ұзарып кетуі
• VM миграциясының баяулауы және VDI-ның шекті сағаттардағы тұрақсыздығы

Егер бірнеше осындай сигнал болса, 10/25/100GbE-ге көшу әдетте ақталған: бұл пайдаланушылар мен сервистерге әсер ететін шыңдарды жоюға бағытталады, жылдамдықты тек жоғарырақ қылу үшін емес.

Есептеу үшін қандай деректер жинау қажет

Өткізу қабілетін есептемес бұрын ағымдағы жүктеме фактілерін жинаңыз. Әйтпесе 10/25/100GbE-ге көшу «көзбен сатып алу» деңгейіне түсіп, кейін бөтелке диск жүйесі, бэкап-окно немесе оптика үйлесімсіздігі болып шығуы мүмкін.

Басты логика: трафикті түрлері бойынша бөліп, әрқайсысының қанша, қашан және кешігулерге қаншалықты сезімтал екенін түсініңіз. Бір стойкада прод-трафик, сақтауға қатынау, резервтік көшіру, репликация және басқару трафигі араласып жатады.

Міндетті бастапқы деректер

Тексеріп қайталай алатын цифрлар жинаңыз:

• Инвентаризация: қанша физикалық хост, қанша VM, сақтау қайда орналасқан, қанша желі порты және узелдердегі жылдамдық қандай.
• Шыңдық және орташа жүктеме: сағат бойынша кіріс және шығыс трафик, prod, storage, backup, репликация және басқаруды бөліп көрсетіңіз.
• Резервтік көшіру: түнде жіберілетін деректер көлемі, керек жылдамдық, окно ұзақтығы, параллель ағымдар саны және қайда жазылады.
• Репликация және миграциялар: қаншалықты жиі және қанша дерек тасымалданады (мысалы, vMotion), жұмыс уақытында шыңдар бар ма.
• Шектеулер: бюджет, стойкадағы бос юниттер, SFP28/QSFP28 модульдерінің қолжетімділігі, кабель түрі (мыс/оптика) және нақты қашықтықтар.

Содан кейін 12–24 айға өсім болжамын қосыңыз: қанша жаңа VM күтіледі, базалар қалай өседі, жаңа сервистер енгізіле ме (VDI, видеобақылау, аналитика). Көбінесе дәл осы өсу қазіргі 10GbE-ні тез қартайтады.

Уақыт бойынша не критикалық екенін бөлек анықтаңыз. Мысалы, RPO 15 минут және RTO 2 сағат — бұл репликация мен қалпына келтіру талаптарын анықтайды, порт жылдамдықтары ғана емес. Егер түнде 20 ТБ-ты 6 сағатта өткізу қажет болса, маңыздысы күндізгі орташа емес, түнгі тұрақты жылдамдық пен накладные шығындарды есептеу.

Виртуализацияға арналған өткізу қабілетін кезең-кезең есептеу

Есептеу порт жылдамдығынан емес, кластерде нақты қандай трафик жүретінін түсінуден басталуы тиіс. Виртуализация үшін тек қолданушылар ғана емес, VM-лар арасындағы алмасу да маңызды.

Түсінікті цифр беретін 5 қадам

1. East-west трафикті бағалаңыз: кластер ішінде кім кіммен сөйлеседі (VM↔DB, VM↔СХД, мониторинг сервисі). Шыңдарды қараңыз, орташа көрсеткіш емес.

2. North-south трафикті бағалаңыз: қолданушыларға, интернетке, филиалдарға шығу. Көбінесе бұл ішкі трафиктен аз болады, бірақ сайттың немесе 1С-тің баяулағанын дәл осы әсер етуі мүмкін.

3. Миграциялар мен қызмет көрсетуді қосыңыз: vMotion/Live Migration, ребилдтер, хост жаңартулары. Қаншалықты жиі және бір уақытта қанша VM көшетінін анықтаңыз.

4. Накладные шығындарды есепке алыңыз: протокол заголовоктары, инкапсуляция (мысалы, VXLAN), шифрлау, зеркало, басшылық трафигі. Өлшенген шыңдардың үстіне 15–30% запас қосу практикалық.

5. Қолайлы oversubscription таңдаңыз: серверлердің жиынтық жылдамдығын бір аплинкке қаншаға бөлуге дайынсыз. 1:1-ге жақын болса, кезектер мен кешігулер азаяды, бірақ шығын жоғары болады.

Сосын аплинктер мен межкоммутаторлық байланыстар жаңа тарлыққа айналмайтынын тексеріңіз. Типтік қате: серверлердегі порттарды жылдамдаттыңыз, бірақ стойкадағы бір ғана 10GbE аплинкты қалдырдыңыз.

Мысал: ToR-ға 8 хост 10GbE арқылы қосылғанда жалпы 80GbE шығады. 4:1 oversubscription кезінде аплинк шамамен 20GbE қажет (әдетте 25GbE-ге әкеледі), ал 2:1-де 40–50GbE керек. Сол себепті 10/25/100GbE-ге көшу цифрлардан туындайды, сәннен емес.

Бэкап пен репликация үшін желіні есептеу

Бэкап желісі көбіне бір үлкен джобтан емес, бірнеше фактордың қосындысынан тұрып «талқандайды»: демалыс күндері толық бэкап, апталық инкременттер, дедупликация, сжатие және әртүрлі серверлерден параллель ағымдар. Сондықтан есептеу — порт жылдамдығын емес, нақты бэкап окнындағы жүктемені негізге алу керек.

Негізгі бағалау оңай: окна үшін жіберілетін деректер көлемі / окно ұзақтығы = ГБ/с. ГБ/с-ті Гбит/с-ке ауыстыру үшін 8-ге көбейтіңіз.

Мысалы: түнде 4 000 ГБ инкрементті 6 сағат ішінде жіберу қажет. 6 сағат = 21 600 секунд. 4 000 / 21 600 ≈ 0,185 ГБ/с ≈ 1,48 Гбит/с таза жылдамдық. Бірақ бұл накладные шығындар, пиковтар және параллель тапсырмаларсыз есеп.

Шындықта резерв әрқашан керек: джобтар шамамен бір уақытта басталады, бір түйінде бірнеше ағым қосылуы мүмкін, патчтар немесе деректердің массалық өзгерістері сияқты «жаман күндер» болады. Дедупликация мен қысу кейде трафикті азайтады, кейде CPU-ға тіреліп жылдамдықты тұрақсыз етеді.

Площадкалар арасындағы репликацияда логика осылайша, бірақ арнаның тұрақтылығы негізгі мәнге ие. Егер сайттар арасындағы канал тар болса, репликация кешігіп, RPO өседі. Ондайда репликацияға лимит қою және оның бэкап немесе прод-трафикпен бәсекелеспеуін қадағалау пайдалы.

10/25/100GbE-ге көшкенде бэкап жылдамдап, бірақ пайдаланушыларға кедергі келтірмеу үшін қарапайым шаралар енгізіңіз: бэкап пен репликацияны бөлек VLAN/интерфейстерге шығару, тапсырмалар жылдамдығын лимиттеу, барлық джобты бір минутта бастамау. Бұл виртуализация мен сақтау тығыз орналасқан түйіндер үшін әсіресе маңызды.

10, 25 немесе 100GbE қалай таңдау керек

Желіні екі деңгейге бөліп қараса оңай: бір узелге (серверге) не керек және бүтін стойкаға аплинктерде не қажет. Әдетте шешім осылай қабылданады және артық шығыннан сақтайды.

10GbE — ToR-коммутаторлар, виртуализация хосттары мен бөлек бэкап сегменті үшін жиі бірінші үлкен қадам. Бұл орташа I/O бар серверлерге және сирек шыңдар болғанда жеткілікті.

25GbE-ні 10-нан сәл жылдам қана деп қарамаңыз; бұл өсуге ыңғайлы келесі баспалдағы: бір портта көбірек запас болады және кейде 1 Гбит/с-қа бағасы тиімдірек, әсіресе порт тығыздығы маңызды болғанда.

100GbE көбінесе әрбір серверге емес, аплинктер мен межстойкалық байланыстар үшін таңдалады: агрегация, spine/leaf, ауыр кластерлерді қосу. Ондай жерлерде бір стойкадан шығатын суммарлы ағын әдетте 2×10 немесе 4×10-ды өтеді.

Практикалық нұсқаулар:

• Узел сирек желіге тірелсе және стойка аплинктері шыңдарда толып кетпесе, 10GbE-де қалу орынды.
• Егер хосттарда көп сөйлейтін VM бар, жиі миграциялар орын алса немесе бэкап пен жұмыс трафигі бір уақытта өтсе — 25GbE алыңыз.
• Стойка аплинктері жиі 2–4 аплинкпен «упираются» болса — 100GbE планлаңыз.
• Порт жылдамдығын ғана емес, жоғарыға қарай суммарлы өткізу қабілетін тексеріңіз.

Бір практикалық сценарий: кейбір серверлерді 10GbE-де қалдырып, жаңа түйіндерді 25GbE-ге қосып, ToR аплинктерін 100GbE ету. Осылайша верхтік қабатты күшейтіп, бірден барлық NIC пен оптиканы ауыстырмайсыз.

Оптика мен кабельдер: сатып алмас бұрын не тексеру керек

10/25/100GbE-ге көшу кезінде жиі ақау оптикасында және оған қатысты бөлшектерде шығады: форм-фактор, кабель түрі, қашықтық, коннекторлардың тазалығы және қуат бюджеттің параметрлері. Осы кезеңдегі қате тұрақсыз сілтемелер мен артық шығындарға әкеледі.

Біріншіден форм-фактор мен жылдамдық үйлесімділігін тексеріңіз. SFP+ — 10GbE, SFP28 — 25GbE, QSFP28 — 100GbE. Модуль физически сай келуі маңызды ғана емес, сонымен қатар коммутатор моделі сол режим мен кодтауды қолдай ма және қажет болса 100G-ді бірнеше 25G-ге (breakout) бөлу мүмкін бе — соны тексеріңіз.

Кейін қашықтық және оптика түрін анықтаңыз. Стойка ішінде және көршілес стойкалар арасында көп режимді (OM3/OM4) қолдану жеткілікті болады. Этажтар немесе корпус арасында ұзақ трассалар үшін бір режимді (OS2) таңдайды. Бұл модульдердің бағасына, коннектор түріне және өту шығындарына әсер етеді.

Физиканы алдын ала бір кестеге жинау пайдалы (порт - модуль - орта түрі - ұзындығы) және үш нәрсені тексеру: сигнал шығыны/қабылдауының жоғалу шегіне сыйады ма, модульдер вендормен және прошивкамен үйлесімді ме, және қай жерде DAC/AOC қолдануға болатынын анықтау.

DAC қысқа қашықтықта (стойка ішінде) арзан әрі қарапайым. AOC икемді және иілу радиусына аз сезімтал. Патч-кордтар мен коннекторлардың сапасына үнемдеуге болмайды — лас коннектор және нашар шнурлар қиын диагностика мен қателерге әкеледі.

Іске қосар алдында қысқа сынақ жоспары жасаңыз: модульдердің сигнал деңгейі мен температурасын (DOM/DDM) тексеріңіз, 1–2 сағат жүктеме жүргізіп CRC/FEC/дроптарды қараңыз, нақты жүктемеде линк флаптарын бақылаңыз. Егер күмән бар болса, патч-кордтарды ауыстырып, мәселе кабельге ауыса ма тексеріңіз.

Коммутаторды таңдау: порт жылдамдығынан басқа не маңызды

Қораптағы порт жылдамдығы коммутатор нақты трафикті көтеретініне кепілдік бермейді. Тарлық көбіне құрылғының ішінде пайда болады: буферлер жетіспейді, ұсақ пакеттердегі өнімділік төмен, аплинктер oversubscription себебінен асып кетеді.

Виртуализацияда трафик араласып келеді: east-west, сақтау, басқару, бэкап. Мұндай комбинацияда гигабиттер ғана емес, коммутатордың кезектер мен приоритеттерді қалай ұстайтыны және мониторингте мәселені қалай көрсететіні маңызды.

Ішкі құрамда және функцияларда тексерілетіндер

• Буферлер мен PPS: қысқа шыңдарды өткізу үшін
• VLAN және LACP: трафикті бөлу және линктерді агрегаттау
• Stack немесе MLAG: екі ToR бір құрылғы сияқты жұмыс істесін
• QoS және телеметрия: бэкаптың бәрін «бұлтқа» батыруға жол бермеу және тез диагностика
• Oversubscription: қанша 25G порты 100G аплинкке жиналатынын есептеңіз

Есепке алынбай қалатын аппараттық заттар

Питание және салқындату: екі БП, ыстық алмастыру, оптикаға арналған қуат қоры, шудың деңгейі. План порттарының резерві: қазіргі және бір жыл ішіндегі 25G порттар саны, аплинктерге қанша 100G қажет болатыны. Әйтпесе апгрейд желіні емес, «темірді» қайта есептеуге апарады.

Практикада 10/25/100GbE-ге көшу максималды жылдамдықтан емес, резервпен және өсуге есептелген ToR-архитектурасынан бастау жақсы. Интегратормен бірге жасасаңыз, oversubscription, төзімділік және мониторинг талаптарын алдын ала бекітіңіз, әйтпесе сатып алу жай ғана тез порттардың жинағы болып қала береді.

Көшіру кезінде жиі жасалатын қателіктер

Ең жиі қате — порттың орташа жүктемесіне ғана қарау. Виртуализация мен сақтау шыңдарын тірейді: түнгі бэкап, репликация, VM-миграциялар. Графикте бәрі әдемі көрінуі мүмкін, бірақ нақты уақытта желі қызметті тоқтатады.

Екінші қате — серверлерді жылдамдату, бірақ жоғары жағындағы бутылканы қалдыру. Мысалы, хосттарға 25GbE қойдыңыз, ал стойка аплингі 10GbE қалды — жаңа карталар әсерін аз көрсетеді.

Оптика мен кабельдарда да жол беру оңай: модульдерді көзбен сатып алу, қашықтық пен порт түріне сәйкес келмеуі. Нәтиже — үйлесімсіздік, линк қателері немесе басқа трансивер түрінің қажеттігі.

Өзіңізді тексеретін қысқа тізім:

• Пиковые нагрузки (бэкапы, репликация, VM-migration) жоспарланған ба?
• Қайда жылдамдықтың шегі: сервер → ToR → аплинк → агрегация → ядро → СХД жолын салыстырдыңыз ба?
• Оптику мен кабельдерді нақты қашықтық пен порт түріне сай таңдап жатырсыз ба?
• Коммутатор ресурстары мен порттарына запас қалдырдыңыз ба?
• Апгрейд алдында мониторинг орнатылған ба, нәтижені өлшеуге бола ма?

Пайдаланушы тәжірибесінен мысал: бір стойкада VM-дар, түнде бэкаптар сақтауға жіберіледі. Күндіз трафик орташа, түнде бэкап пен репликация бір уақытта жүктелгенде аплинк бітеліп, порттарда кезектер өседі — таңертең тапсырмалар баяу басталады. Егер тек серверлік NIC-ті өзгертіп, аплинк пен сақтау порттарын қалдырсаңыз, мәселе қалады, тек анықталуы қиын болады.

Апгрейдке дейінгі жылдам чеклист

1–2 жұмыс күні ішінде желі шынымен жылдамдықпен шектеліп тұрғанын дәлелдейтін белгілерді жинаңыз. Бір баяу сервис желі деген ұғым болуы мүмкін, бірақ себебі басқа болуы да мүмкін: перегруженный хост, СХД немесе бэкап жоспары.

Чеклист:

• Порттар піковое уақытта тұрақты түрде 70–80% және одан жоғары ұстап тұр ма, әрі кешігулер өсуде ме?
• Коммутатор порттарында дроптар, қателер немесе кезектер бар ма, әсіресе бэкап/миграция уақытында?
• Бэкап окно прод-қа айтарлықтай әсер етіп отыр ма (таңертең баяулаулар, конкуренция)?
• VM миграциялары мен сақтау ребалансі бұрынғыдан әлдеқайда ұзақ па?
• Қайда 10GbE жеткілікті, қай жерде 25GbE тиімді, және қай жерде 100GbE қажет — картаңыз бар ма?

Физиканы сатып алмас бұрын тағы тексеріңіз: модульдер мен кабельдер серверлер мен коммутаторлармен үйлесімді ме, нақты қашықтық сәйкес келе ме (DAC/оптика/типа волокна). Типтік қате — SFP28/QSFP28 сатып алып, соңынан үйлесімсіздікке тап болу.

Мысал сценарий: виртуализация + түнгі бэкап бір стойкада

Стойкада 6 хост виртуализация. Әрқайсысында 20–30 VM, ортақ сақтау ToR арқылы қосылған, түнде толық бэкап бір репозиторийге жүреді. Алғашқы проблемалар әдетте түнде пайда болады. 1/10GbE жүйесі шыдайды, бірақ бэкап, фоновая репликация және күнделікті VM-жұмыстары бір уақытта қосылса, аплинк қалыңданып, порттарда кезектер өсіп, VM кешігеді.

Апгрейд алдындағы типтік көрініс:

• Бэкап окно уақытынан тысқа шығып, жұмыс уақытында жалғасады.
• ToR порттарында жоғары жүктеме мен микрошабуылдар байқалады.
• Сақтауға немесе vMotion-ға latency өседі, VM-дар қысқа уақытқа тұрып қалады.
• Апаттан кейін қалпына келтіру күткендегіден баяу.

Жеңіл жоспар: хосттарды 25GbE-ге көтеріп, стойка аплинктерін 2×100GbE жасау (немесе қажеттіліге қарай көбірек). Бэкапқа бөлек сегмент беру: жеке VLAN/VRF, бөлек порттар немесе жеке коммутатор, түнгі трафик виртуализацияға әсерін азайтсын.

Нәтижені көзбен емес, метрикалармен тексеріңіз: порттардың жүктемесі, drop/CRC, кезектер, p95 кешігу до СХД, бэкаптың нақты жылдамдығы және окноның жабылу уақыты. Тестті нағыз шың уақытына жүргізіңіз, тыныш уақытта емес.

Өсу үшін ToR таңдағанда 25GbE порттарына запас пен қосымша 100GbE аплинктерді қосып алу пайдалы, сонда келесі екі хостты қосқанда толық қайта құру қажет болмайды.

Келесі қадамдар: енгізу жоспары және одан әрі не істеу керек

Тарлықтарды анықтап, қажетті өткізу қабілетін есептегеннен кейін бірден сатып алуға кіріспеңіз. Алдымен нақты карта жинаңыз: серверлер мен СХД қайда тұр, линктердің жылдамдықтары қандай, қай жерде аплинк ядроға шығады, қай жерде бөлек желілер (басқару, storage, VM, бэкап), межстоечные байланыстар қайда.

Одан әрігі жоспар тәуекелді азайтып, нақты жүктеме бойынша нәтижелер береді:

• Стойкалар бойынша порттар мен жылдамдықтық схеманы жинаңыз: хосттар, СХД, аплинк, interconnect, ағымдағы SFP/QSFP түрлері және ұзындықтар.
• Бір стойкада пилот жасаңыз: жаңа жылдамдықты қосып, әдеттегі түнгі бэкаптар мен виртуализация жүктемесін өткізіп, метрикаларды алыңыз (порт жүктемесі, кешігулер, жоғалту, бэкап оконның қысқаруы).
• Спецификация дайындаңыз: коммутаторлар, модульдер, кабельдар және критикалық элементтерге 1–2 запас зат қойыңыз.
• Қолдау жоспарын жасаңыз: инциденттерге кім жауап береді, алмастыру қанша уақытта мүмкін, запас элементтер қайда сақталады, откат тәртібі және 24/7 талаптары.
• Адымы бойынша енгізу: стойкадан стойкаға, бақылау нүктелері мен табыстың анық критерийлерімен (мысалы, бэкап окна X сағатқа қысқарды, аплинк жүктемесі Y%-дан асқан жоқ).

Егер жобаны жобалау, серверлер, желілік бөліктер мен оптиканың үйлесімдігін таңдау үшін ресурстар жеткіліксіз болса, GSE.kz (gse.kz) компаниясымен кеңескен ыңғайлы. Компания деректер орталықтарының инфрақұрылымдық шешімдерін және тәулік бойы техникалық қолдауды ұсынады — бұл апгрейд критикалық сервистерге әсер еткенде пайдалы.