Zoning FC SAN: Brocade пен Cisco MDS үшін қауіпсіз ережелер

Қай жерде көбінесе инциденттер болады при изменениях FC SAN

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

Көбіне қолжетімділіктің бұзылуы zoning-тен болады: ол қай портты «көре алатынын» анықтайды. Егер сервер мен СХД бір-бірін көрмей қалса, мультипатинг жолдарды жоғалтады, ал ОС пен қолданбалар әртүрлі жауап береді: өнімділіктің нашарлауынан бастап толық тоқтауға дейін.

Типтік салдарлар:

• қолданбалардың тоқтауы — LUN-ға барлық жолдар жоғалғанда
• бір бөлігі жолдар жоғалғанда деградация (I/O тек бір жолдан өтеді, кідірістер өседі)
• активациядан кейін «жыпылықтайтын» жолдар, егер артық немесе қиысқан зоналар қалған болса
• күрделі диагностика, себебі мәселе бірден көрінбеуі мүмкін (мысалы, жүктеме шыңында)

Түптен алғанда себеп көбіне өзгерістер процесінде: «тірі» түзетулер без плана возврата, WWPN пен атаулардағы шатасу, single-initiator және «жалпы» зоналарды араластыру, және ең қауіптісі — қате конфигурацияны Activate/Enable ету немесе Activate/Enable кейін нақты не өзгеретінін түсінбеу.

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

Негізгі терминдер — бір тілде сөйлесетін болу үшін

Көп инциденттер адамдар әртүрлі заттарды бір атаумен атайтындықтан немесе идентификаторларды шатастырудан басталады.

WWPN (World Wide Port Name) — FC порттың уникалды адресі. Бұл MAC-адрес емес (ол Ethernet үшін) және құрылғының сериялық нөмірі емес. Құрылғының бір сериялық нөмірі болуы мүмкін, ал HBA порттарының WWPN-дері екі (немесе одан көп) болады. WWPN HBA-ны ауыстырғанда немесе кейбір жаңартулардан кейін өзгеруі мүмкін.

FC-да әдетте екі роль бар:

• Инициатор (initiator) — HBA бар сервер, ол дискке сұрау жібереді.
• Таргет (target) — СХД порты, ол сұрауды қабылдайды.

Қарапайым логика: сервер тек қажет таргеттерді көруі керек, бәрін емес.

Негізгі объектілер:

• Alias — WWPN-ге түсінікті атау (мысалы, srv01_hba1 немесе storageA_ctrl0_p1).
• Zone — кім кіммен араласа алады деген ереже (әдетте инициатор + қажетті таргеттер).
• Zoneset (Cisco) немесе cfg (Brocade) — фабрикада қолданыста болатын зоналардың жинағы.

Cisco MDS үшін маңызды деталь: VSAN — бір коммутатор ішіндегі виртуалды фабрикалар. Zoning пен активация нақты бір VSAN шеңберінде болады. Бір WWPN жұбы басқа VSAN ішінде ештеңе бермейді.

Көп жағдайда нақты инфрақұрылымда екі тәуелсіз фабрика A/B болады. Бұл серверден СХД-ға екі бөлек жол — төзімділік үшін. Зонирлеуді екі Fabrica-да қайталау керек, бірақ соқты-сықпай көшірудің қажеті жоқ: WWPN мен порттардың Fabric A мен Fabric B-ге сай екеніне көз жеткізіңіз.

Қате ықтималдығын төмендететін zoning ережелері

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

1) Single-initiator zoning

Ең пайдалы ереже: бір инициатор (бір HBA-порт, бір WWPN) — бір зона. Зонада сол инициатордан басқа тек қажетті target-порттар болады.

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

2) Міндетті қажетті қолжетімділік

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

Әдетте әр фабрикаға (A немесе B) және қажетті төзімділік деңгейіне сай порттар жиынтығын таңдайды.

3) Бірыңғай және оқылатын атаулар

Атаулар көмектесу керек, жұмбақ болмауға тиіс. Жақсы схема әдетте хостты, HBA нөмірін, рөлді (init/target), массивті, портты және фабриканы көрсетеді. Солай түнгі өзгерістерде WWPN-ді шатастыру немесе «ұқсас» объектіні қосу ықтималдығы азаяды.

Минималды нейминг ережелері:

• WWPN алиастары мен зоналар үшін бір формат
• Fabric A/B атауда айқын көрсетілуі
• «Түсініксіз» қысқартуларға рұқсат жоқ (немесе сөздікпен бекіту)
• Brocade пен Cisco MDS үшін бірдей принцип

Қашан ерекшеліктерге рұқсат етіледі

Кейде ережеден шығу қажет болады: ортақ дискі бар кластерлер, tape sharing сценарийлері немесе вендор талаптары. Маңыздысы — ерекшелік саналы түрде қабылдансын және жазылып тұрсын: неге, қай хосттарға арналған, кім келіскен және өзгертуден кейін не тексерілетіні. Олай болмағанда «уақытша» шешім тез тұрақты проблемалар көзіне айналады.

Өзгерістер енгізудің қадамдық алгоритмі (жалпы)

Инциденттер көбіне «күрделі командалардан» емес, асығысдықтан және толық емес мәліметтерден болады. Бірдей әрекет тәртібін ұстансаңыз, тәуекел айтарлықтай азаяды.

Өзгерістерге дейін: дайындық және факт жинау

Өтінішке тәртіп керек: не қосасыз, неге, қай терезеде, кім нәтиже қабылдайды. Кері қайтару жоспарын алдын ала дайындаңыз: егер хост LUN көрмесе немесе керісінше артық нәрсе көрсе не қайтарып алынады.

Фабриканы өзгертуге дейін минимум жинаңыз:

• инициаторлардың (HBA) WWPN-дері және СХД таргет порттарының WWPN-дері
• физикалық қосылған switch-порттар және олардың ағымдағы күйі
• қолжетімділік моделі («кең» зоналардан аулақ)
• уақыт шектері мен табыс критерийлері (не «жұмыс істейді» деп есептеледі)
• ОС және СХД жақтан тексеруді жауапты адам

Сосын фактілерді тексеріңіз: бір символды қате WWPN-да үлкен тоқтап қалуды шақыруы мүмкін.

Орындау және бақылау

Кішкентай қадамдармен жұмыс істеңіз және әрбір қадамды тексеріңіз:

• жаңа WWPN-дер үшін түсінікті алиастар жасаңыз (хост пен target), сонда «тегіс» мәндермен жұмыс істемейсіз
• жаңа зонаны жасаңыз: «инициатор + қажетті target-порттар» (артық қатысушыларсыз)
• зонаны активті жинаққа (zoneset/cfg) қосыңыз, басқа зоналарды өзгертпеңіз, тек қажет болса
• келісілген терезеде өзгерістерді белсенділеңіз және конфигурация қателіксіз қолданылғанына көз жеткізіңіз
• хост пен СХД-да көріністі тексеріңіз, соңынан 10–30 минут бақылаңыз: логиндер, жол қателері, флаппинг

Мысал: жаңа серверді СХД-ға қосасыз. Екі HBA WWPN-ін тіркеп, массивтің target-порттарын таңдап, әрбір fabric үшін бір зона жасайсыз және тек содан кейін белсендіріп қоюсыз. Егер қате шықса, қайтару — бұрынғы активті жинаққа оралу.

Жұмыстан кейін күнін, терезені, кім жасағанын, қосылған WWPN мен алиастарды, қай зоналар қай жинаққа қосылғанын және хост пен СХД тексерісінің нәтижесін жазып алыңыз. Келесі өзгеріс пен инцидентті зерттеуде бұл сағаттарды үнемдейді.

Brocade: практикалық ережелер және типтік команда тәртібі

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

Алиастар мен зоналар: қарапайым құрылым

Алиастар құрылғы мен портты көрсетуі керек, ал зоналар — инициатор-таргет жұбын.

Жиі қолданылатын тәсіл:

• Алиастар: SRV_<host>_HBA1, SRV_<host>_HBA2, STG_<array>_P1, STG_<array>_P2
• Зоналар: Z_<host>_HBA1_<array>_P1 (бір жолға бір зона)
• Конфиг: fabric-та бір активті cfg, мысалы CFG_PROD

«Кең» зоналардан аулақ болыңыз: оларды тексеру мен инцидентті шешу қиындайды.

Типтік команда реттігі (логика)

Реттіліктің мәні: алдымен алиастар мен зоналар, кейін cfg-ге қосу, содан соң активация.

alicreate "SRV_APP01_HBA1", "10:00:00:00:00:00:00:01"
alicreate "STG_A_P1",        "50:00:00:00:00:00:00:A1"

zonecreate "Z_APP01_HBA1_STGA_P1", "SRV_APP01_HBA1; STG_A_P1"

cfgadd "CFG_PROD", "Z_APP01_HBA1_STGA_P1"

cfgenable "CFG_PROD"
cfgsave

Негізгі ереже: cfgenable орындамас бұрын сіз дұрыс cfg-ны өзгеріп жатқаныңызға және тек қажетті зоналарды қосып жатқаныңызға сенімді болыңыз.

cfgenable орындағанда күтпеген өзгерістер болмауы үшін

cfgenable конфигурацияны толық түрде қолданады, сондықтан «сюрприздер» басқа адамдардың сақталмаған түзетулерінен немесе cfg-лар шатасуынан пайда болады.

Активациядан бұрын тексеріңіз:

• қазіргі уақытта қай cfg белсенді және қай cfg-ны қосасыз
• параллель жұмыстар жоқ па, zoning-ке түзетулер бар ма
• WWPN-дер дұрыс па (қате көбіне «тыныш жұмыс істемей тұрғандай» көрінеді)
• қажетті порттардың күйі (online, дұрыс жылдамдық)
• порттардағы қате санағыштары (CRC, link resets), себебін zoning-қа қосып алмаңыз

Сенімсіз болсаңыз, алиастар мен зоналарды дайындап қойыңыз, бірақ cfgenable-ды келісілген терезеге қалдырыңыз. Бұл көпшілік қайта логин мен қолданба шағымдарын түзетуден арзанырақ.

Cisco MDS: практикалық ережелер және типтік команда тәртібі

Cisco MDS-та қателіктер көбіне синтаксисте емес, контексте болады: VSAN дұрыс емес, fabric-та қате, порттар жарамсыз. Сондықтан алдымен тексерулерден бастаңыз, содан кейін зоналарды жасаңыз.

Device-alias және нейминг: шатаспаудың тәсілдері

Барлық хосттар мен массив порттары үшін device-alias пайдаланыңыз және бірдей шаблон ұстаныңыз (мысалы, srv-<аты>-hba0, stor-<аты>-p1). Маңыздысы — alias WWPN-ге бірмәнді сәйкес болу керек.

Ережелер:

• Alias арқылы жұмыс істеңіз, WWPN-ды тікелей қолданбаңыз (шұғыл жағдайлардан басқа).
• Бір зона — бір анық инициатор-таргет жұбы, артық қатысушыларсыз.
• Әр VSAN үшін бөлек zoneset.
• Өзгерістерді белсенді емес zoneset-ке енгізіп, тек тексергеннен кейін белсендіріңіз.
• Өзгерістерді A және B fabrics-қа симметриялы енгізіңіз, бірақ кезекпен, қайтару терезесі қалсын.

Зоналар, zoneset, VSAN және активация

Төменде типтік команда реттігі берілген: алдымен алиастар, содан соң зоналар, zoneset-ке қосу және қажетті VSAN-да активация.

conf t
  device-alias database
    device-alias name srv-app01-hba0 pwwn 20:00:00:xx:xx:xx:xx:01
    device-alias name stor-a-ct0-p1  pwwn 50:00:00:yy:yy:yy:yy:11
  device-alias commit

  zone name Z_APP01_CT0_P1 vsan 10
    member device-alias srv-app01-hba0
    member device-alias stor-a-ct0-p1

  zoneset name ZS_PROD vsan 10
    member Z_APP01_CT0_P1
end

zoneset activate name ZS_PROD vsan 10

Егер бірнеше VSAN және түрлі fabrics болса, бұл ақпаратты атауда сақтаңыз (мысалы, ZS_PROD_V10, ZS_TEST_V20) және «мен дәл сол контекстпін» дегенге сенбеңіз. Екінші fabric-та сол қадамдарды қайталаңыз, бірақ WWPN мен VSAN жоспарға сәйкес екеніне көз жеткізіңіз.

Активациядан кейін команда орындағанымен шектелмеңіз. Фактілерді тексеріңіз: зона шынымен де қажетті VSAN-ның активті zoneset-інде ме, мүшелері күтілген WWPN-дерге сай ма, инициатор мен таргет Name Server-де көрініп жатыр ма, логиндер көтерілді ме және хост пен СХД-да қажет жолдар пайда болды ма, артық құрылғылар жоқ па.

Өзгерістерге дейін және кейін қандай тексерістер міндетті

Күтілетін мен нақты жағдай сәйкес келмесе проблема туындайды. Өзгерістерге дейін 10 минут жұмсау жақсы нәтиже береді.

Өзгерістерге дейін тексеріңіз

• WWPN: сервердің HBA-лары дұрыс па және массивтің порттары дұрыс па (жиі қате — HBA0 пен HBA1-ді шатастыру немесе WWNN-ды WWPN орнына қолдану).
• Қазіргі көрініс: сервер қазір қандай құрылғыларды көреді және осы WWPN-дер үшін қандай зоналар бар.
• Атаулар қақтығысы: бірдей алиас немесе бір атаумен әр түрлі құрам (қаңғары түзетулерден кейін пайда болады).
• «Минималды қолжетімділік» принципі: жоспарланған зонада тек сервер мен қажетті массив порттары бар.
• Бастапқы күй: активті конфигурацияның снимогы (қай жерге қайтаруға болатынын білу үшін).

Жылдам салыстыру үшін күтулер кестесін алдын ала толтырыңыз.

Өзгерістерден кейін дереу тексеріңіз

Тек «пайда болды ма» ғана емес, «артық пайда болды ма» дегенді де тексеріңіз. Фактикалық көріністі кестемен салыстырыңыз: күтілген порттар ғана көрініп тұр ма, екі HBA арқылы жолдар көтерілді ме, артық таргеттер жоқ па.

Егер серверде мультипатинг болса, жолдардың фабрикаларға дұрыс бөлінгенін тексеріңіз (мысалы, әр фабрика арқылы бір жол). Екі фабрикада өзгерістер симметриялы енгізілгенін тексеріңіз.

Өзгерістер журналында мінімум жазылуы тиіс:

• кім және қашан өзгертті
• не өзгертілді (WWPN, алиастар, зоналар)
• мақсат (қай сервер, қай СХД, қандай тапсырма)
• тексеріс нәтижесі (күтілген/нақты)
• кері қайтару жоспары

Zoning-тағы жиі қателіктер және торлар

Zoning инциденттері әдетте күрделі командалардан емес, деректер сәйкес еместігінен және «жедел істеу» әдетінен болады.

Идентификаторлар мен «ескі» порттармен шатасу

Классика — WWNN мен WWPN-ды шатастыру. Zoning үшін әдетте нақты порттың WWPN-ы керек, WWNN емес. Қате айқын емес: зона белсенді, бірақ хост LUN-ды көрмейді — себебі фабрикада «қате» идентификатор бар.

Екінші жиі жағдай — ескірген WWPN. Серверді қайта орнатқаннан, HBA-ны ауыстырғаннан немесе VM-ді басқа хостқа жылжытудан кейін құжаттарда және алиастарда ескі WWPN қалады. Сол кезде сіз қолжетімділікті «босқа» ашасыз, ал қажетті порт зонада болмайды.

«Тым кең» зона

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

Активациядан бұрын типтік тұзақтарды қарап шығыңыз:

• Алиаста WWNN орнына WWPN берілген не WWPN қате порттан алынған
• HBA ауыстырғаннан кейін тарихтағы WWPN-дер қолданылып қалған
• Бір зонада бірнеше инициатор бар, қажетсіз
• Өзгерістер активті zoneset-те тікелей жасалып, кері қайтару нүктесі жоқ
• Атаулар құрамды түсіндірмейді және қайталанбайды

Fabric A/B сәйкессіздігі

Одан бөлек ауыр мәселе — Fabric A дұрыс болса, Fabric B ұмытылып қалуы. Сырттан бәрі жұмыс істеп тұрған сияқты көрінеді, бірақ бір жол ғана бар: бір HBA логин жасап, екіншісі қолжетімсіз, мультипатинг degraded күйге өтеді.

Қауіпті төмендету үшін қарапайым ережелер:

• Алиастар атауы: роль + хост + порт (мысалы, SRV01_HBA0).
• Зона атауы: инициатор + таргет + fabric (құрам көрінетіндей болу үшін).
• Активациядан бұрын A және B өзгерістердің симметриясын тексеріңіз.
• Қайтару үшін активті конфигурацияның снимогын жасаңыз.

Үлкен инфрақұрылымдарда, онда ондаған серверлер мен СХД қосылғанда, мұндай тәртіп өте маңызды: бір WWPN қатесі бірнеше инцидент тізбегіне әкелуі мүмкін.

Activate/Enable баспас бұрын қысқа чек-лист

Активтендіру алдында 2 минут тоқтаңыз. Көп инциденттер шағын сәйкессіздіктерден болады: қате WWPN, дұрыс емес zoneset немесе зонада кездейсоқ қосылған хост.

Brocade Activate немесе Cisco MDS enable zoneset батырмасын басардан бұрын тексеріңіз:

• WWPN екі дереккөзден расталған (мысалы, ОС/утилита HBA және fabric login). Инициаторлар мен таргеттер қай joyda екенін біліңіз.
• Алиастар бір шаблон бойынша жасалған және анық оқылады (хост, HBA A/B, массив, порт). Еркін мәтін және ұқсас атаулар болмауы тиіс.
• Әр зона бір инициатор мен тек қажетті таргеттер принципіне сай жасалған.
• Сіз зоналарды дұрыс zoneset/cfg-ге және дұрыс fabric/VSAN-ға қосып жатқаныңыз анық. Контекст екі рет тексерілген.
• Кері қайтару жоспары жазылған және реалистік: нақты не қайтарылады, қай командамен және кейін не тексеріледі.

Сосын қысқа «ойша симуляция» жасаңыз: нақты сервер үшін не өзгереді? Жаңа хост қосқанда тек қажетті жолдар пайда болуы керек, көршілердің ешқайсысы өзгермеуі тиіс.

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

Өмірден мысал: жаңа серверді СХД-ға сюрпризсіз қосу

Тапсырма: екі HBA-сы бар жаңа сервер, екі FC-коммутатор (Fabric A және Fabric B) және екі контроллері бар массив (SP A және SP B). Мақсат — серверге тек қажетті LUN-дармен қолжетімділік беру және бар серверлерге әсер етпеу.

Алдымен деректерді жинап, оларды fabric-тар бойынша бөліңіз. Серверде әр HBA порттың WWPN-ін алыңыз (WWNN-ды шатастырмаңыз). Массивте Fabric A және Fabric B үшін target-порттардың WWPN-дерін алдын ала шешіп қойыңыз. Ереже: HBA0 тек Fabric A target-порттарымен, HBA1 тек Fabric B target-порттарымен жұмыс істесін — осылай жолдарды араластырмауға болады.

Өзгеріс жөнінде дайындықтың бір үлгісі:

• хосттың аты және HBA0/HBA1 WWPN-дері
• массивтің Fabric A және Fabric B үшін target WWPN-дері
• болашақ зоналардың атаулары (бір шаблон бойынша)
• өзгеріс болмайтындар тізімі (бар зоналар/алиастар)
• жұмыс терезесі және кері қайтару жоспары

Одан әрі zoning single-initiator, single-target принципімен жүргізіледі. Әр fabric-та бөлек зона жасалады: HBA0 -> targetA және HBA1 -> targetB. Солай фабрика артық қолжетімділікті ашпайды: егер массивте бір жерде қате болса да, артық құрылғылар SAN деңгейінде пайда болмайды.

Еске сала кететін жайт: LUN-ға қолжетімділік әлі де массив жағында маскирлеу (host/initiator groups, LUN mapping) арқылы шектелуі керек.

Активациядан кейін барлық жолдар көтерілгеніне көз жеткізіңіз: коммутаторда порттар Online, сервер таргеттерді көреді, ал ОС/мультипатинг жолдар күйі күтілгендей (мысалы, Active/Optimized).

Егер кейбір жолдар көтерілмесе, жиі себебі:

• WWPN-ды шатастыру (WWNN немесе басқа HBA порты алынды)
• зона дұрыс fabric-та жасалмаған немесе қате target-порт көрсетілген
• коммутатор портында логин жоқ (кабель/SFP/жылдамдық)
• массивте initiator үшін mapping жасалмаған
• серверде HBA порты өшірілген немесе драйвер параметрлері қате

Осындай сценарий әдетте тыныш өтеді, себебі әр өзгеріс локаль және қадаммен тексеріледі.

Келесі қадамдар: стандарттар, регламент және қолдау

Негізгі ережелер түсінікті болғаннан кейін тәуекелдерді одан әрі азайту — баршаға бірдей тәсілді келісу. Zoning технологиясы сирек бұзылады; көбіне мәселе өзгерістердің әртүрлі «стилінде» және тәртіптің болмауында.

Нейминг стандарты және шаблондар

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

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

• алиастар, зоналар және конфигтер үшін бірдей формат (хост, HBA-порт, СХД, фабрика, орта)
• шаблон «бір хост порты — бір массив порты» (немесе таңдалған стандарт) және ерекшеліктер қашан рұқсат етілетіні
• қысқа мысалдар жинағы, жаңадан келгендер ол арқылы жұмыс істесін

Өзгерістер регламенті және SAN «гигиенасы"

Регламент қысқа және міндетті болу керек. Ол асығыстықтан қорғайды: кім келіседі, қай терезеде, қалай қайтарылады, не тексеріледі, қайда жазылады.

Көбінесе жеткілікті:

• жұмыс жоспары: не өзгереді, қандай порттар, қандай зоналар әсерленеді
• жұмыс терезесі және «тоқтау» критерийлері
• кері қайтару жоспары: не және қай реттілікпен қайтарылады
• алдынғы және кейінгі тексерістер және өзгерістер журналы

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

Егер SAN жобалауда немесе қызметте көмек қажет болса, интеграторды тартқан жөн — ол стандарттар мен регламентті орнатып, 24/7 қолдау қызметін ұсына алады. Мысалы, GSE.kz (gse.kz) — ЦОД инфрақұрылымымен және 24/7 қолдаумен жұмыс істейтін жүйелік интегратор, бұл SAN өзгерістерін тар шекті терезелерде әрі нәтижені тіркеп жасау керек болғанда ыңғайлы.