Бұл мақала «Желілік инфрақұрылымды қалай басқаруға болады» мақалалар сериясының екінші мақаласы. Сериядағы барлық мақалалардың мазмұнын және сілтемелерді табуға болады .
Бұл кезеңдегі мақсатымыз – құжаттама мен конфигурацияны ретке келтіру.
Бұл процестің соңында сізде қажетті құжаттар жинағы және оларға сәйкес конфигурацияланған желі болуы керек.
Енді біз қауіпсіздік аудиті туралы айтпаймыз - бұл үшінші бөлімнің тақырыбы болады.
Бұл кезеңде берілген тапсырманы орындаудың қиындығы, әрине, әр компанияда айтарлықтай өзгереді.
Идеал жағдай - бұл
- сіздің желіңіз жобаға сәйкес жасалған және сізде құжаттардың толық жинағы бар
- сіздің компанияңызда жүзеге асырылды желі үшін
- осы процеске сәйкес сізде ағымдағы жағдай туралы толық ақпарат беретін құжаттар (барлық қажетті диаграммаларды қоса) бар
Бұл жағдайда сіздің тапсырмаңыз өте қарапайым. Құжаттарды зерттеп, енгізілген барлық өзгерістерді қарап шығу керек.
Ең нашар сценарийде сізде болады
- жобасыз, жоспарсыз, рұқсатсыз, біліктілігі жеткілікті деңгейде жоқ инженерлер құрған желі;
- хаотикалық, құжатсыз өзгерістермен, көптеген «қоқыспен» және оңтайлы емес шешімдермен
Сіздің жағдайыңыз бір жерде екені анық, бірақ, өкінішке орай, бұл жақсы шкала бойынша - одан да жаманы, сіз ең нашар аяқталуға жақын болу ықтималдығы жоғары.
Бұл жағдайда сізге ойларды оқу мүмкіндігі де қажет болады, өйткені сіз «дизайнерлердің» не істегісі келетінін түсінуді, олардың логикасын қалпына келтіруді, аяқталмаған нәрсені аяқтауды және «қоқыстарды» жоюды үйренуіңіз керек.
Және, әрине, сіз олардың қателерін түзетуге, дизайнды өзгертуге (осы кезеңде мүмкіндігінше аз) және схемаларды өзгертуге немесе қайта құруға тура келеді.
Бұл мақала ешбір жағдайда толық деп есептемейді. Мұнда мен тек жалпы принциптерді сипаттаймын және шешілуі керек кейбір жалпы мәселелерге тоқталамын.
Құжаттар жинағы
Мысалдан бастайық.
Төменде дизайн кезінде Cisco Systems жүйесінде әдетте жасалатын кейбір құжаттар берілген.
CR – Тұтынушының талаптары, клиенттің талаптары (техникалық шарттар).
Ол тұтынушымен бірлесіп құрылады және желіге қойылатын талаптарды анықтайды.HLD – Жоғары деңгейлі дизайн, желі талаптарына (CR) негізделген жоғары деңгейлі дизайн. Құжат қабылданған архитектуралық шешімдерді түсіндіреді және негіздейді (топология, хаттамалар, аппараттық құралдарды таңдау,...). HLD интерфейстер мен пайдаланылған IP мекенжайлары сияқты дизайн мәліметтерін қамтымайды. Сондай-ақ, арнайы аппараттық конфигурация мұнда талқыланбайды. Керісінше, бұл құжат тұтынушының техникалық басшылығына дизайнның негізгі тұжырымдамаларын түсіндіруге арналған.
LLD – Төмен деңгейлі дизайн, жоғары деңгейлі дизайнға (HLD) негізделген төмен деңгейлі дизайн.
Онда жобаны іске асыруға қажетті барлық мәліметтер, мысалы, жабдықты қосу және конфигурациялау туралы ақпарат болуы керек. Бұл дизайнды жүзеге асыруға арналған толық нұсқаулық. Бұл құжат біліктілігі төмен қызметкерлердің оны жүзеге асыруы үшін жеткілікті ақпаратты қамтамасыз етуі керек.Мысалы, IP мекенжайлары, AS нөмірлері, физикалық коммутация схемасы (кабельдік) бөлек құжаттарда «шығарылуы» мүмкін, мысалы. NIP (Желілік енгізу жоспары).
Желінің құрылысы осы құжаттарды жасағаннан кейін басталады және оларға қатаң сәйкес келеді, содан кейін тапсырыс берушімен жобаға сәйкестігін тексереді (сынақтар).
Әрине, әртүрлі интеграторлар, әртүрлі клиенттер және әртүрлі елдер жобалық құжаттамаға әртүрлі талаптар қоюы мүмкін. Бірақ мен формальдылықтан аулақ болып, мәселені мәні бойынша қарастырғым келеді. Бұл кезең дизайнмен емес, заттарды ретке келтірумен байланысты және тапсырмаларды орындау үшін бізге жеткілікті құжаттар жинағы (сызбалар, кестелер, сипаттамалар...) қажет.
Менің ойымша, белгілі бір абсолютті минимум бар, онсыз желіні тиімді басқару мүмкін емес.
Бұл келесі құжаттар:
- физикалық коммутацияның (кабельдік) диаграммасы (журнал)
- желілік диаграмма немесе L2/L3 маңызды ақпараты бар диаграммалар
Физикалық коммутация диаграммасы
Кейбір шағын компанияларда жабдықты орнатуға және физикалық коммутацияға (кабельдік) байланысты жұмыстар желілік инженерлерге жүктеледі.
Бұл жағдайда мәселе келесі тәсілмен ішінара шешіледі.
- оған не қосылғанын сипаттау үшін интерфейстегі сипаттаманы пайдаланыңыз
- барлық қосылмаған желілік жабдық порттарын әкімшілік түрде өшіріңіз
Бұл сізге сілтемеде ақаулық туындаған жағдайда да (cdp немесе lldp осы интерфейсте жұмыс істемейтін кезде) осы портқа не қосылғанын жылдам анықтауға мүмкіндік береді.
Сондай-ақ, сіз жаңа желілік жабдықтың, серверлердің немесе жұмыс станцияларының қосылымдарын жоспарлау үшін қажетті порттардың қайсысын алып жатқанын және қайсысы бос екенін оңай көре аласыз.
Бірақ жабдыққа қол жеткізе алмай қалсаңыз, бұл ақпаратқа да қол жеткізе алмайтыныңыз анық. Сонымен қатар, осылайша сіз қандай жабдық, қандай қуат тұтыну, қанша порт, қандай сөреде, қандай патч-панельдер бар және қай жерде (қандай сөреде/патч-панельде) сияқты маңызды ақпаратты жаза алмайсыз. ) олар байланысты. Сондықтан қосымша құжаттама (жабдықтағы сипаттамалар ғана емес) әлі де өте пайдалы.
Идеал нұсқа ақпараттың осы түрімен жұмыс істеуге арналған қолданбаларды пайдалану болып табылады. Бірақ сіз өзіңізді қарапайым кестелермен шектей аласыз (мысалы, Excel бағдарламасында) немесе қажет деп санайтын ақпаратты L1/L2 диаграммаларында көрсете аласыз.
Маңызды!
Желілік инженер, әрине, SCS-тің қыр-сырлары мен стандарттарын, тіректердің түрлерін, үздіксіз қуат көздерінің түрлерін, суық және ыстық өтпелердің не екенін, жерге қосуды қалай дұрыс жасау керектігін жақсы біледі ... элементар бөлшектердің физикасын немесе C++ тілін білу. Бірақ мұның бәрі оның білім саласы емес екенін әлі де түсіну керек.
Сондықтан жабдықты орнатуға, қосуға, техникалық қызмет көрсетуге, сондай-ақ физикалық коммутацияға қатысты мәселелерді шешу үшін арнайы бөлімдер немесе арнайы адамдар болуы жақсы тәжірибе болып табылады. Әдетте деректер орталықтары үшін бұл деректер орталығының инженерлері, ал кеңсе үшін бұл анықтамалық қызмет.
Егер сіздің компанияңызда мұндай бөлімшелер қарастырылған болса, онда физикалық коммутацияны тіркеу мәселелері сіздің міндетіңіз емес және сіз интерфейстегі сипаттамамен және пайдаланылмаған порттарды әкімшілік өшірумен ғана шектеле аласыз.
Желілік диаграммалар
Диаграммаларды салудың әмбебап тәсілі жоқ.
Ең бастысы, диаграммалар сіздің желіңіздің логикалық және физикалық элементтері арқылы трафиктің қалай өтетінін түсінуді қамтамасыз етуі керек.
Физикалық элементтер деп біз айтамыз
- белсенді жабдық
- белсенді жабдықтың интерфейстері/порттары
Логикалық астында -
- логикалық құрылғылар (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Виландар
- ішкі интерфейстер
- тоннельдер
- аймақ
- ...
Сондай-ақ, егер сіздің желіңіз толығымен қарапайым болмаса, ол әртүрлі сегменттерден тұрады.
Мысалы
- деректер орталығы
- интернет
- WAN
- қашықтан қол жеткізу
- кеңсе LAN
- DMZ
- ...
Үлкен суретті (барлық осы сегменттер арасындағы трафиктің қалай жүретінін) және әрбір жеке сегменттің егжей-тегжейлі түсіндірмесін беретін бірнеше диаграммалар болғаны дұрыс.
Заманауи желілерде көптеген логикалық қабаттар болуы мүмкін болғандықтан, әртүрлі қабаттар үшін әртүрлі схемаларды жасау жақсы (бірақ қажет емес) тәсіл болуы мүмкін, мысалы, қабаттастыру тәсілі жағдайында бұл келесі схемалар болуы мүмкін:
- қабаттасу
- L1/L2 астыңғы қабаты
- L3 астындағы төсем
Әрине, ең маңызды диаграмма, онсыз дизайн идеясын түсіну мүмкін емес, маршруттық диаграмма.
Маршруттау схемасы
Кем дегенде, бұл диаграмма бейнеленуі керек
- қандай маршруттау протоколдары қолданылады және қайда
- маршруттау протоколының параметрлері туралы негізгі ақпарат (аумақ/AS нөмірі/маршрутизатор идентификаторы/…)
- Қай құрылғыларда қайта бөлу орын алады?
- сүзгілеу және маршрутты біріктіру орын алатын жерде
- әдепкі маршрут туралы ақпарат
Сондай-ақ, L2 схемасы (OSI) жиі пайдалы.
L2 схемасы (OSI)
Бұл диаграмма келесі ақпаратты көрсетуі мүмкін:
- қандай VLAN
- қандай порттар магистральдық порттар болып табылады
- қай порттар эфирлік арнаға (порт арнасы), виртуалды порт арнасына біріктірілген
- қандай STP протоколдары және қандай құрылғыларда қолданылады
- негізгі STP параметрлері: түбірлік/түбірлік сақтық көшірме, STP құны, порт басымдылығы
- қосымша STP параметрлері: BPDU қорғаушы/сүзгі, түбірлік қорғау…
Әдеттегі дизайн қателері
Желіні құруға дұрыс емес тәсілдің мысалы.
Қарапайым кеңсе LAN құрудың қарапайым мысалын алайық.
Студенттерге телекоммуникацияны үйретуде тәжірибем бар деп айта аламын, екінші семестрдің ортасында кез келген студент қарапайым кеңсе LAN орнату үшін қажетті білімге (мен оқытқан курстың бөлігі ретінде) ие.
Коммутаторларды бір-біріне қосу, VLAN, SVI интерфейстерін орнату (L3 қосқыштары жағдайында) және статикалық маршруттауды орнатудың қиындығы неде?
Барлығы жұмыс істейді.
Бірақ сонымен бірге, қатысты сұрақтар
- қауіпсіздік
- брондау
- желіні масштабтау
- өнімділік
- өткізу қабілеті
- сенімділік
- ...
Кейде мен кеңседегі LAN өте қарапайым нәрсе деген мәлімдемені естимін және мен мұны әдетте желілерден басқаның бәрін жасайтын инженерлерден (және менеджерлерден) естимін және олар мұны соншалықты сенімді айтады, сондықтан LAN болатынына таң қалмаңыз. тәжірибесі мен білімі жеткіліксіз адамдар жасаған және мен төменде сипаттайтын шамамен бірдей қателіктермен жасалады.
Жалпы L1 (OSI) дизайн қателері
- Дегенмен, сіз SCS үшін де жауапты болсаңыз, онда сіз алуы мүмкін ең жағымсыз мұралардың бірі абайсыз және ойластырылмаған ауысу болып табылады.
Мен сондай-ақ пайдаланылатын жабдықтың ресурстарына қатысты L1 типті қателерді жіктер едім, мысалы,
- өткізу қабілетінің жеткіліксіздігі
- жабдықта TCAM жеткіліксіз (немесе оны тиімсіз пайдалану)
- жеткіліксіз өнімділік (көбінесе брандмауэрмен байланысты)
Жалпы L2 (OSI) дизайн қателері
Көбінесе, STP қалай жұмыс істейтіні және онымен бірге қандай ықтимал проблемалар әкелетіні туралы жақсы түсінік болмаған кезде, қосқыштар әдепкі параметрлермен, STP қосымша баптауынсыз ретсіз қосылады.
Нәтижесінде бізде жиі мынадай жағдайлар болады
- үлкен STP желісінің диаметрі, бұл хабар тарату дауылдарына әкелуі мүмкін
- STP түбірі кездейсоқ анықталады (mac мекенжайы негізінде) және трафик жолы оңтайлы емес болады
- хосттарға қосылған порттар шет (портфаст) ретінде конфигурацияланбайды, бұл соңғы станцияларды қосу/өшіру кезінде STP қайта есептеуіне әкеледі.
- желі L1/L2 деңгейінде сегменттелмейді, нәтижесінде кез келген коммутаторға қатысты мәселелер (мысалы, қуатты шамадан тыс жүктеу) STP топологиясын қайта есептеуге және барлық коммутаторлардағы барлық VLAN желілеріндегі трафикті тоқтатуға әкеледі (соның ішінде үздіксіз қызмет сегменті тұрғысынан маңызды)
L3 (OSI) дизайнындағы қателердің мысалдары
Жаңадан бастаушыларға тән бірнеше қателіктер:
- Статикалық маршруттауды жиі пайдалану (немесе тек пайдалану).
- берілген дизайн үшін оңтайлы емес маршруттау хаттамаларын пайдалану
- оңтайлы емес логикалық желі сегментациясы
- маршруттарды біріктіруге мүмкіндік бермейтін мекенжай кеңістігін оңтайлы емес пайдалану
- резервтік маршруттар жоқ
- әдепкі шлюз үшін брондау жоқ
- маршруттарды қайта құру кезінде асимметриялық бағыттау (NAT/PAT, күйі бар брандмауэрлер жағдайында маңызды болуы мүмкін)
- MTU проблемалары
- маршруттар қайта салынған кезде, трафик басқа қауіпсіздік аймақтары немесе тіпті басқа желіаралық қалқандар арқылы өтеді, бұл трафиктің төмендеуіне әкеледі.
- топологияның нашар масштабталуы
Жобалау сапасын бағалау критерийлері
Оңтайлылық/оптималды еместігі туралы айтқанда, біз мұны қандай критерийлер тұрғысынан бағалауға болатынын түсінуіміз керек. Міне, менің көзқарасым бойынша, ең маңызды (бірақ барлығы емес) критерийлер (және маршруттау хаттамаларына қатысты түсініктеме):
- ауқымдылық
Мысалы, сіз басқа деректер орталығын қосуды шешесіз. Сіз мұны қаншалықты оңай жасай аласыз? - пайдаланудың қарапайымдылығы (басқару мүмкіндігі)
Жаңа торды жариялау немесе маршруттарды сүзу сияқты операциялық өзгерістер қаншалықты оңай және қауіпсіз? - қолжетімділігі
Жүйеңіз уақыттың қанша пайызын қажетті қызмет деңгейін қамтамасыз етеді? - қауіпсіздік
Жіберілген деректер қаншалықты қауіпсіз? - баға
Өзгерістер
Бұл кезеңдегі негізгі принципті «зиян келтірмеу» формуласымен көрсетуге болады.
Сондықтан дизайнмен және таңдалған іске асырумен (конфигурациямен) толық келіспесеңіз де, әрқашан өзгертулер енгізу ұсынылмайды. Ақылға қонымды тәсіл барлық анықталған проблемаларды екі параметр бойынша бағалау болып табылады:
- бұл мәселені қаншалықты оңай шешуге болады
- ол қаншалықты тәуекелге ұшырайды?
Ең алдымен, қазіргі уақытта ұсынылатын қызмет көрсету деңгейін қолайлы деңгейден төмендететін нәрсені жою қажет, мысалы, пакеттердің жоғалуына әкелетін проблемалар. Содан кейін тәуекел дәрежесінің төмендеу ретімен түзетілетін ең оңай және қауіпсізді түзетіңіз (жоғары тәуекелді дизайн немесе конфигурация мәселелерінен тәуекелі төменге дейін).
Бұл кезеңде перфекционизм зиянды болуы мүмкін. Дизайнды қанағаттанарлық күйге келтіріңіз және сәйкесінше желі конфигурациясын синхрондаңыз.
Ақпарат көзі: www.habr.com