Brocade пен Cisco MDS SAN үшін: буферлер, лицензиялар, ISL, диагностика

Brocade пен Cisco MDS-ті SAN үшін салыстыруды қайдан бастауға болады

SAN-коммутаторларды салыстыру жиі брендтен емес, нақты проблемадан басталады: түсініксіз кешігулер, сирек кадр қателері, пиктік бэкаптар кезінде «ұсталулар» немесе фабриканы сенімді әрі болжамды түрде кеңейтуді қалау. Сондықтан «Brocade vs Cisco MDS для SAN» деген сұрақты былайша қайта қою дұрыс: кеңейту немесе ауыстырудан кейін не нәрсе тұрақты әрі болжамды болуы тиіс.

Порттардың жылдамдығына ғана сүйенбеу маңызды. 16G/32G және тіпті 64G өздерімен бірге нақты жүктемеде кезектер, кредиттердің жетіспеушілігі және межкоммутаторлық байланыстардың шамадан тыс жүктелуін болдырмайды деген кепілдік бермейді. SAN тұрақтылығына көбіне каталогта тосын көрінетін, ал эксплуатацияда бәрін шешетін детальдар әсер етеді.

Адал салыстыру үшін қарапайым бастапқы деректерден бастаңыз. Проблемалар қай жерде көрінеді (бэкап, VM миграциясы, репликация, хосттар санының өсуі)? Топология мен өсім жоспары қандай (коммутатор қанша, ISL қанша, біртұтас фабрика немесе сегментация)? Қандай сервистер критикалық (СХД, виртуализация, дерекқорлар, VDI, медициналық жүйелер, төлем жүйелері)? Ал қай шектеулер бірден маңызды (лицензиялар, қолдау, жеткізу мерзімі, локал контент талаптары, вендор саясаты)?

Осы деректерсыз «кім жақсы» деген салыстыру болжамға айналады. Кейін ғана спецификацияларды талдап, оларды практикада тексерудің мәні бар.

Бастапқы деректер: жүктеме, өсім және ақауға төзімділік

Brocade пен Cisco MDS-ті салыстырғанда моделдер мен лицензиядан емес, сіздің SAN профилінен бастаңыз. Бірдей коммутатор кейде VDI-ны жақсы ұстайтын болса, түнгі бэкаптар кезінде шектеліп қалуы мүмкін.

Ағымдағы SAN-ның қысқа паспортын жинаңыз. Тек «порт қанша» деп емес, кім және қалай қолданатынын, бүгін қандай жылдамдық қажет екенін және ертең не қосылатынын белгілеңіз.

Бір бетте тіркеңіз:

• қанша хост және қандай жылдамдықтарда (16G/32G/64G) қанша HBA порт шұғылданған;
• қанша массив бар, репликацияға, snapshot немесе бэкапқа арналған жеке порттар бар ма;
• қандай ағындар басым (дерекқордың тұрақты I/O, VDI шыңдары, түнгі бэкаптар, жаппай миграциялар);
• ақауға төзімділік қалай ұйымдастырылған (бір фабрика немесе екі, рафтар/сайткалар бойынша бөліну);
• 1–3 жылға өсім жоспары (жаңа полкалар, кластерлер, жоғары жылдамдыққа көшу).

Шектеулерді бөлек талқылаңыз. Кейде таңдау «қайсысы техникалық жақсырақ» емес, жеткізу мерзімі, сатып алу ережелері мен қолдау бюджетіне байланысты шешіледі.

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

Буферлер: спецификацияларды қалай оқу керек және неге маңызды

SAN-коммутатордағы буферлер — Fibre Channel кадрлары үшін қысқа «кезек». Тұрақты трафикте олар байқалмайды, бірақ қысқа жарылыстарда (микроберсттер) буферлер трафиктің жоғалуын болдырмау немесе қайта жіберулерді азайту тұрғысынан шешуші рөл атқарады.

Порттың шамадан тыс жүктелуі әрдайым «дискілер тартады» дегенді білдірмейді. Тар орын күтпеген жерде пайда болуы мүмкін: мысалы, бір баяу буын (16G байланысы 32G ортасында) кезек туғызады және кейін көрші ағындар зардап шегеді. Жеткілікті буферлер қысқа пикті сезілмей өткізуге көмектеседі.

Спецификацияларда тек «жалпы буфер көлеміне» емес, оның қалай бөлінетініне назар аударыңыз. Brocade пен Cisco MDS-дегі формулировкалар даташитте әртүрлі беріледі — осында қателесу оңай.

Құжаттамада және конфигурацияда тексеруге пайдалы нәрселер:

• портқа арналған буфер: фиксирленген пе, әлде жалпы пулдан динамикалық бөлінеді ме;
• ортақ буфер пулы бар ма және ол порттар арасында қалай бөлінеді;
• E-порттарға (ISL) және F-порттарға (хосттар/массивтер) буфер айырмашылығы бар ма;
• кейбір функциялар қосылғанда (QoS, шифрлау, аналитика) шектеулер бар ма;
• жүктеме кезінде мінез-құлық қалай сипатталған: тастау ма әлде credit-based backpressure ма.

Практикада буфер проблемалары жиі «жүзетін» кешігулер және сирек, бірақ ауыр құлдыраулар ретінде көрінеді: бэкап жылдам өтіп, кенет баяулайды; дерекқор таймаут береді, ал массив өз метрикасында «таза». Мұны СХД-дағы проблемамен шатастыру оңай.

Дегенмен симптомдарды араластырмаңыз. CRC/encoding қателері немесе келісімсіз жылдамдықтың тұрақсыздығы бар болса — физиканы, SFP/кабельдерді және скорост сәйкестігін алдымен жөндеңіз. Физика таза болғаннан кейін ғана буферлер туралы қорытынды жасаңыз.

Кредиттер мен «аштық»: өнімділік құлдырауларының типтік себептері

Fibre Channel-де кадр жіберу ережелері қатаң: порт қашықтағы жақтан buffer-to-buffer кредит алғаннан кейін ғана кадр жібере алады. Кредиттер жеткіліксіз болса, порт күтуге кіріседі, және сіз өткізу қабілетінің төмендеуін байқайсыз — бұл credit starvation.

Симптомдарға мысал: тұрақты перегруз жоқ, бірақ кешігулер өседі, бэкаптар уақыт бойынша «шашылады», кейбір хосттар latency-дің кескінін байқатады. Көбіне проблема фабриканың бір ISL-ында немесе бір «батыл» портта көрінеді, ол бірнеше «шулы» ағынды қызмет етеді.

Типтік себептер қарапайым:

• ұзын трасса немесе қалааралық байланыс (латенция артса, линкті толтыруға көбірек кредит қажет);
• соңындағы баяу құрылғы (лента, ескі полка, асып кеткен массив) кредиттерді баяу қайтарады;
• тізбектегі жылдамдықтардың сәйкес келмеуі (мысалы 32G алдыда, 16G кейін) және тар жерде кезек пайда болуы;
• транзиттік East-West трафигі көп болғандықтан ISL-дың асуы;
• фабриканың дизайнындағы қателер — тым көп трафик бір деңгей арқылы өтеді.

ISL мен буферлер тікелей байланысты: фабрика ұлғайған сайын транзиттік трафиктің үлесі өседі және ISL порттары белсендірек кредиттер жұмсайды. Сондықтан Brocade пен Cisco MDS-ті тек «жалпы буфер бойынша» салыстырмаңыз — нақты кешігулер мен жүктеме қоспасы жағдайында порттардың мінезін қараңыз.

Адал салыстыру үшін бірдей уақыт аралығында бірдей метрикаларды алыңыз:

• кредиттер күту уақытының үлесі (credit wait);
• utilization және p95/p99 кешігулер;
• ISL бойынша counters: congestion, discards, timeouts;
• қате счетчиктер: CRC, encoding, link resets;
• кезек және oversubscription статистикасы негізгі порттарда.

Егер мәселе эпизодтық болса, баптаулар көмектесуі мүмкін: жылдамдықтарды сәйкестендіру, ағындарды орналастыру, ISL балансын реттеу, trunking параметрлері. Егер кредит аштығы жүктеме кезінде тұрақты қайталанса, көбіне архитектураны өзгерту қажет: ISL-ді көбею немесе жылдамдату, трафикке басқа жолдар ұйымдастыру, «ауыр» ағындарды тарату, топологияны қайта қарау.

ISL және trunking: фабриканы тәжірибе жүзінде қалай салыстыруға болады

ISL — межкоммутаторлық сызықтар — жиі байқалмайтын тар орын болады: хосттар мен СХД жылдам көрінсе, коммутаторлар арасына кадрлар жиналуы мүмкін. Brocade мен Cisco MDS-ті ISL бойынша салыстырғанда порт санына емес, фабрика нагрузкасында қалай әрекет ететініне мән беріңіз: бэкаптар, репликация, күндік шыңдар.

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

Салыстырудан бұрын критерийді бекітіңіз: бэкап уақытында бір ISL жоғалғанда не болатынын бағалаңыз. Егер сол мезетте кешігулер мен қателер байқалса — фабрика «шетінде» жобаланған.

Trunking пен баланс бойынша тек «қолданады» деген жауап жеткіліксіз — мінез-құлықты тексеріңіз:

• топтағы сызықтардың жылдамдықтары мен оптикасы бірдей ме;
• порт баптаулары мен trunking режимдерінің екі жағында үйлесімділігі бар ма;
• ағындар тең бөлінеді ме, әлде «бірі толы, екіншісі бос» жағдайы бар ма;
• сызық қосқанда/өшіргенде қысқа мерзімді құлдыраулар бола ма.

Оптиканы және жылдамдықтарды араластырмай анық жоспар құрыңыз — формальді trunk бар, бірақ трафик күтпегенше бөлінуі мүмкін. ISL-ді өсімге және шыңдарға арналған резервпен жобалау (әдетте бэкап пен репликацияны есепке алып) пайдалы. Практикалық амал — орташа емес, 95-перцентильді есептеп, 12–18 айға өсімді қосу.

Лицензиялар: құрам мен иелік құнын қалай дұрыс бағалау керек

Brocade пен Cisco MDS арасындағы лицензиялық модельдер бағадан бөлек сіз жасай алатын архитектураға да әсер етеді. Кең тараған қате — коммутатор сатып алған соң қажетті функциялардың опция екені анықталуы.

Лицензияларды екі жазықтықта қараңыз. Архитектуралық лицензиялар фабрика мүмкіндіктерін өзгертеді (trunking, порттарды кеңейту, сегментация/виртуализация, қосымша протоколдар). Эксплуатациялық лицензиялар өткізу қабілетін арттырмаса да диагностиканы, телеметрияны және логтарды сақтау мүмкіндігін береді.

Ең жағымсыз TCO моделі — «базалық + опциялар»: бастапқы жеткізілім минималды сценарийді ғана қамтиды, ал желі өскен сайын қосымша төлемдер тізбегі басталады. Бүгін 24 порт және бір ISL жеткілікті болса, келер жылы екінші коммутатор қосылғанда лицензиялар, агрегация немесе кеңейтілген бақылау үшін қосымша төлем керек болуы мүмкін.

Тең әділ салыстыру үшін баға сұрауына дейін талаптарды бекітіңіз:

• қазір және 12–24 айдан кейін қанша активті порт қажет;
• қанша ISL, қандай жылдамдық, trunking керек пе;
• сегментация және трафик оқшаулануы қажет пе;
• кеңейтілген аналитика мен логтардың ұзақ сақтауына қажеттілік бар ма;
• бүкіл фабрикаға бірегей лицензиялау тәсілі керек пе.

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

Диагностика жайлылығы: құралдар мен логтарға неге қарап бағалау керек

Диагностиканы таңдау соңғы сәтте ойланғанға қарағанда маңызды — содан кейін нақты ол шешімнің инцидентті іздеу-шағаруға кететін сағаттарды анықтайды.

Күнделікті жұмыста сирек қажетті терең утилитадан гөрі келесі сұрақтарға жылдам жауап беру маңызды: қате қайда, қай портта, бұл SFP/кабель ме, ISL ме әлде құрылғы ма. Жақсы көрсеткіш — базалық ақпарат CLI мен GUI-де бірдей қолжетімді болуы: порт статус, жылдамдық, counters, кредиттер мен перегрузтар, флаптар тарихы және әрі қарай не істеу керектігі туралы анық жолдау.

Не табылуы тиіс 1–2 минут ішінде:

• порт қателері (CRC, loss of sync, enc out) және уақыт бойынша динамика;
• ISL пен trunking жағдайы, жүктеу және линктер арасындағы дисбаланс;
• оптика мәселелерінің белгілері (Rx/Tx power, DOM ескертулері, шекті оқиғалар);
• дроп/переполнение счетчиктері және буфер/кредиттен туындайтын «аштық» белгілері;
• фабрика картасы: кім кімге қосылған және жұмыстардан кейін не өзгерді.

Логтар мен оповещениелер: жіберіп алмауға тиіс оқиғалар — порт flap, оптика деградациясы, ISL down, жаппай қателер, zoning өзгерістері, ресурс шектеулері, қайта жүктеу немесе фабриканың рөлін өзгеру. Хабарламалар «қатесыз тізім» емес, нақты себеп пен порт/модульге байланыстырылған болуы керек.

Сатып алудан бұрын стендке қолжеткізу сұрап, 15–20 минут ішінде «мәселені таптым — себебін түсіндірдім — метрикамен растады» тізбегін сынап көріңіз. Бұл тәжірибе ұзақ инцидентте кететін уақыты айқындайды.

Инфрақұрылымыңыз үшін қадамдық салыстыру әдісі

Brocade мен Cisco MDS салыстыруын жарнамалық кестелер арқылы емес, өз деректеріңіз бойынша жүргізу оңайырақ: қай жерде буферлер мен кредиттер маңызды, қай жерде ISL жетіспейді, қай жерде диагностика мен лицензиялар шешеді.

Бес қадамдық схема жиі ең адал нәтиже береді:

1. Ағымдағы SAN бойынша деректер жинаңыз: қолданылған порттар, 12–24 айға қажеттілік, жылдамдықтар, топология, ISL саны, trunking болуы.
2. Жүктемелер мен шыңдарды сипаттаңыз: бэкап қай уақытта, репликация, үлкен VM миграциялар, қай сағаттарда кешігулер жиі байқалады.
3. Симптомдарды талаптарға аударыңыз: алыс сызықтағы құлдыраулар — буферлер мен кредиттерге сұраныс; ISL-дың шектелуі — агрегация, тең тарату және өткізу қабілетінің резерві сұранысы.
4. Бір бетті матрица жасаңыз: функциялар (trunking, zoning, VSAN/фабрика виртуализациясы, шифрлау, телеметрия), лицензиялар және олардың міндеттілігі, сіздің стекпен үйлесімділік, 3–5 жылдық TCO есеп.
5. 2–3 типтік операцияда пилот өткізіңіз: бэкап, жаппай миграция/клонирлеу, репликация. Өлшеулерді тек жылдамдықпен емес, кешігулердің тұрақтылығымен, қателермен және логтардың сапасымен алыңыз.

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

SAN-коммутатор таңғанда жиі жасалатын қателіктер

Ең жиі қате — тек прайс-лист бойынша порт саны арқылы салыстыру. SAN-да маңыздысы — порттардың қалай байланысатыны және фабриканың пиктерді қалай өткеруі. ISL-ды бағаламау хосттар мен СХД формальды қосылғанымен, трафик коммутаторлар арасындағы тар жерде тұрып қалатын ситуацияға әкеледі.

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

Үшінші — жылдамдықтар мен оптиканы араластыру. Жартылай 32G, жартылай 16G, әртүрлі SFP және ұзындықтар. Фабрика «жұмыс істеуі» мүмкін, бірақ CRC көбеюі, retransmit артуы және уақытша құлдыраулар пайда болады. SAN-да мұндай ұсақ мәселелер тез созылмалы проблемаға айналады.

Тағы бір жиі қате — диагностикаға «әдемі панельге» қарап баға беру, бірақ нақты первопричинаны счетчиктер, кредиттер, кезектер және оқиғалар бойынша қаншалықты тез табатынын есепке алмау.

Пилотқа дейін қабылдау критерийлерін бекітіңіз: мақсатты ISL схемасы (сан, жылдамдық, trunking), тексерілетін счетчиктер мен шектер, жүктеме сценарийі (мысалы, бэкап плюс I/O шыңы), кеңейту жоспары және нәтижені растауға жауапты тұлғалар.

Сатып алу мен пилотқа дейінгі жедел чек-лист

Деректер дәл болған сайын, «қағазда дұрыс келетін» бірақ нақты жүктемеде күтпегенше мінез көрсететін коммутаторды сатып алу мүмкіндігі азаяды.

Тексеріңіз:

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

Сосын «диагностика жайлылығы» қалай өлшенетінін келісіңіз, әйтпесе пилот әсерге негізделген сезімдерге айналады. Әдетте жеткілікті 3–4 тест: ISL-ды асыра жүктеу мен кешігуді салыстыру, сызықты жасанды нашарлату және себепті табуға кеткен уақыт, пиковая буфер/кредит жағдайын тексеру, және қауіпсіз қайта оралу жоспары (trunk/ISL баптауларын өзгерткеннен кейін).

Екі ЦОД болса және ұзын ISL бар болса — дәл сол учаскеде пилот өткізіңіз. Онда кредиттер, оптика және коммутатор «не болып жатқанын» қаншалықты түсінікті түсіндіретіні жиі көрінеді.

Орташа ұйымға арналған сценарий мысалы

Орташа ұйым: екі фабрика (Fabric A және Fabric B), шамамен 250–300 VM, прод пен тест үшін бөлек массивтер, тар терезеде түнгі бэкап. Бір жыл ішінде жаңа хосттар мен полкалар қосылып, East-West трафик өсті (vMotion, репликациялар, бэкап).

Симптомдар бірден байқалмады. Шың сағатында кей бэкап тапсырмалары терезеден шығып кетті, кей VM-лердің диск кешігуі өсті. Коммутатор метрикаларынан көрінгені: ядро мен шет арасында ISL жиі шекті жүктелуге жетеді, ал ұзын трассалы порттарда кредит жетіспеуіне байланысты кешігулер байқалады.

Brocade пен Cisco MDS салыстыру үшін талаптар матрицасын жасады: қазір және 2 жылдағы жылдамдық, ISL саны, trunking қажеттілігі, мониторинг функциялары, міндетті лицензиялар. Сосын типтік тапсырмаларда пилот жүргізді: бэкап, жаппай vMotion, параллель LUN көшірмелері.

Пилот кезінде нақты көрсеткіштер жиналды: ISL жүктемесі мен микропиктер, discards пен drop-тар, credit starvation белгілері, порт кезегі мен кешігулері, және логтар арқылы первопричинаны табуға кеткен уақыт.

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

Әрі қарай не істеу: әрекет жоспары және кімге тапсыру керек

1–2 беттік қысқа құжаттан бастаңыз: қазіргі жағдай, ауырсыну нүктелері, қандай жақсартулар қажет. Бұл Brocade пен Cisco MDS салыстыруды тексерілетін критерийлерге айналдырады.

Кіріс деректер мен бағалау критерийлерін уақтылы бекітіңіз: порттар мен жылдамдықтар, ISL бүгін және бір жыл ішінде, буфер мен кредит тәуекелдері, лицензиялар (базада не бар, не қосылады), диагностика талаптары (қандай счетчиктер мен алерттер), және эксплуатациялық аспектілер (жаңартулар, SFP ауыстырылуы, конфигтің бэкапталуы).

Келесі қадам — пилот. Ол даташит оқудан гөрі пайдалы, себебі сіздің жағдайыңызда фабриканың мінезін көрсетеді. Алдын ала метрикалар мен сәттілік шектерін таңдаңыз: кешігудің тұрақтылығы, қателер өсімінің болмауы, ISL тоқтағаннан кейінгі түсінікті қалпына келтіру.

Егер аудит пен пилотты сыртқа бергіңіз келсе, команда таңдаңыз, олар SAN-ды сезім емес, метрикалар мен сценарийлер бойынша тексере білсін. Қазақстанда мұндай жұмыстарды GSE.kz-ке жүктеуге болады: олар салыстыру матрицасын даярлап, пилот ұйымдастырып, әрі қарай 24/7 қолдауды қамтамасыз ете алады.