Бул макала "Тармактык инфраструктураңызды кантип көзөмөлдөө керек" деген макалалар сериясынын экинчиси. Сериядагы бардык макалалардын мазмунун жана шилтемелерди тапса болот .
Бул этапта биздин максатыбыз документацияга жана конфигурацияга тартипке келтирүү.
Бул процесстин аягында сизде керектүү документтердин топтому жана аларга ылайык конфигурацияланган тармак болушу керек.
Эми биз коопсуздук аудиттери жөнүндө сөз кылбайбыз - бул үчүнчү бөлүктүн предмети болот.
Бул этапта берилген тапшырманы аткаруунун кыйынчылыгы, албетте, компаниядан компанияга абдан өзгөрүп турат.
идеалдуу кырдаал качан болуп саналат
- Сиздин тармагыңыз долбоорго ылайык түзүлгөн жана сизде документтердин толук топтому бар
- Сиздин компанияңызда ишке ашырылган тармак үчүн
- бул процесске ылайык, сизде учурдагы абал жөнүндө толук маалымат берүүчү документтер (анын ичинде бардык зарыл болгон диаграммалар) бар
Бул учурда, сиздин милдет абдан жөнөкөй. Сиз документтерди изилдеп, бардык киргизилген өзгөртүүлөрдү карап чыгышыңыз керек.
Эң начар сценарийде сизде болот
- квалификациясынын жетишээрлик деңгээлине ээ болбогон инженерлер тарабынан долбоорсуз, плансыз, бекитилбестен түзүлгөн тармак;
- башаламан, документсиз өзгөрүүлөр менен, көп "таштанды" жана субоптималдуу чечимдер менен
Сиздин абалыңыз ортодо экени түшүнүктүү, бирок, тилекке каршы, бул масштабда жакшыраак - андан да жаманы, сиз эң жаман акырга жакындап калуу ыктымалдыгы жогору.
Бул учурда, сизге акылды окуу жөндөмү да керек болот, анткени сиз "дизайнерлердин" эмнени каалашканын түшүнүп, алардын логикасын калыбына келтирип, бүтпөгөн нерсени бүтүрүп, "таштандыларды" алып салууну үйрөнүшүңүз керек.
Жана, албетте, алардын каталарын оңдоо, өзгөртүү (бул этапта мүмкүн болушунча минималдуу) дизайн жана схемаларды өзгөртүү же кайра түзүү керек болот.
Бул макала эч кандай түрдө толук деп ырастабайт. Бул жерде мен жалпы принциптерди гана сүрөттөп, чечилиши керек болгон кээ бир жалпы көйгөйлөргө токтолом.
Документтердин топтому
Келгиле, бир мисал менен баштайлы.
Төмөндө дизайн учурунда адатта 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
- Vilans
- ички интерфейстер
- туннелдер
- зоналар
- ...
Ошондой эле, эгерде сиздин тармагыңыз толугу менен элементардык эмес болсо, анда ал ар кандай сегменттерден турат.
Мисалы,
- маалымат борбору
- Интернет
- 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 дарегинин негизинде) жана трафик жолу субоптималдуу болот
- хостторго туташкан порттор чет (portfast) катары конфигурацияланбайт, бул акыркы станцияларды күйгүзүүдө/өчүрүүдө STP кайра эсептөөсүнө алып келет
- тармак L1/L2 деңгээлинде сегменттелбейт, мунун натыйжасында кандайдыр бир коммутатордогу көйгөйлөр (мисалы, кубаттуулукту ашыкча жүктөө) STP топологиясын кайра эсептөөгө жана бардык өчүргүчтөрдөгү бардык VLANларда трафикти токтотууга алып келет (анын ичинде үзгүлтүксүздүк кызмат сегменти көз карашы боюнча бир сындуу)
L3 (OSI) дизайнындагы каталардын мисалдары
Жаңы баштаган тармактын бир нече типтүү каталары:
- Статикалык маршрутизацияны тез-тез колдонуу (же колдонуу гана).
- берилген долбоор үчүн субоптималдуу маршруттук протоколдорду колдонуу
- субоптималдуу логикалык тармак сегментациясы
- дарек мейкиндигин оптималдуу эмес пайдалануу, бул маршрутту бириктирүүгө мүмкүндүк бербейт
- резервдик жолдор жок
- демейки шлюз үчүн резервация жок
- маршруттарды кайра курууда ассиметриялык маршруттоо (NAT/PAT, мамлекеттик брандмауэрлер үчүн маанилүү болушу мүмкүн)
- MTU менен көйгөйлөр
- каттамдар кайра курулганда, трафик башка коопсуздук зоналарынан же башка брандмауэрлерден өтөт, бул трафиктин токтоп калышына алып келет
- топологиянын начар масштабдалышы
Долбоордун сапатын баалоо критерийлери
Оптималдуу/оптималдуу эместиги жөнүндө сөз кылганда, биз муну кандай критерийлер менен баалай аларыбызды түшүнүшүбүз керек. Бул жерде, менин көз карашым боюнча, эң маанилүү (бирок баары эмес) критерийлер (жана маршрутташтыруу протоколдоруна байланыштуу түшүндүрмөлөр):
- масштабдуулугу
Мисалы, сиз дагы бир маалымат борборун кошууну чечесиз. Сиз муну канчалык оңой кыла аласыз? - колдонуунун жөнөкөйлүгү (башкаруу)
Жаңы торду жарыялоо же маршруттарды чыпкалоо сыяктуу операциялык өзгөрүүлөр канчалык оңой жана коопсуз? - жеткиликтүүлүгү
Сиздин системаңыз талап кылынган тейлөө деңгээлин канча пайыз менен камсыздайт? - коопсуздук
Өткөрүлгөн маалыматтар канчалык коопсуз? - баа
өзгөрүүлөр
Бул этаптагы негизги принцип "зыян кылба" формуласы менен көрсөтүлүшү мүмкүн.
Ошондуктан, сиз дизайнга жана тандалган ишке ашырууга (конфигурацияга) толугу менен макул болбосоңуз да, өзгөртүүлөрдү киргизүү дайыма эле максатка ылайыктуу эмес. Акылга сыярлык мамиле бардык аныкталган көйгөйлөрдү эки параметр боюнча баалоо болуп саналат:
- бул маселени кантип оңой эле чечсе болот
- ал канчалык тобокелге салат?
Биринчиден, учурда көрсөтүлүүчү кызматтардын деңгээлин алгылыктуу деңгээлден төмөндөтүп жаткан нерсени, мисалы, пакеттин жоголушуна алып келген көйгөйлөрдү жоюу зарыл. Андан кийин тобокелдиктин даражасын төмөндөтүү иретинде оңдоого эң оңой жана коопсуз болгон нерсени оңдоңуз (жогорку коркунучтуу дизайн же конфигурация маселелеринен коркунучу төмөн болгондорго чейин).
Бул этапта перфекционизм зыяндуу болушу мүмкүн. Дизайнды канааттандырарлык абалга келтириңиз жана тармак конфигурациясын ошого жараша синхрондоңуз.
Source: www.habr.com