Гэты артыкул з'яўляецца другім у цыкле артыкулаў "Як узяць сеткавую інфраструктуру пад свой кантроль". Змест усіх артыкулаў цыклу і спасылкі можна знайсці .
Наша мэта на дадзеным этапе - навядзенне парадку ў дакументацыі і канфігурацыі.
На вынахадзе гэтага працэсу ў вас павінен быць неабходны камплект дакументаў і сетка, сканфігураваная ў адпаведнасці з імі.
Цяпер мы не будзем казаць аб аўдыце бяспекі - гэтаму будзе прысвечана трэцяя частка.
Складанасць выканання пастаўленай на гэтым этапе задачы, вядома, моцна вар'іруецца ад кампаніі да кампаніі.
Ідэальная сітуацыя - гэта калі
- ваша сетка была створана ў адпаведнасці з праектам і вы маеце поўны камплект дакументаў
- у вашай кампаніі быў укаранёны для сеткі
- у адпаведнасці з гэтым працэсам вы размяшчаеце дакументамі (у тым ліку і ўсімі неабходнымі схемамі), якія прадстаўляюць поўную інфармацыю аб актуальным становішчы рэчаў
У гэтым выпадку ваша задача дастаткова простая. Вы павінны вывучыць дакументы і прагледзець усе тыя змены, якія былі зроблены.
У горшым варыянце ў вас будзе
- сетка, створаная без праекта, без плана, без узгаднення, інжынерамі, якія не валодаюць дастатковым узроўнем кваліфікацыі,
- з хаатычнымі, не задакументаванымі зменамі, з вялікай колькасцю «смецця» і неаптымальных рашэнняў
Зразумела, што ваша сітуацыя недзе паміж, але, на жаль, на гэтай шкале лепш - горш з вялікай верагоднасцю, вы будзеце знаходзіцца бліжэй да горшага канца.
У гэтым выпадку, ад вас запатрабуецца ў тым ліку і ўменне чытаць думкі, таму што вам давядзецца навучыцца разумець, а што ж хацелі зрабіць "дызайнеры", аднаўляць іх логіку, дарабляць тое, што не было скончана і выдаляць "смецце".
І, вядома, вам трэба будзе купіраваць іх памылкі, змяняць (на гэтым этапе па магчымасці мінімальна) дызайн і змяняць ці ствараць нанова схемы.
Дадзены артыкул ні ў якай меры не прэтэндуе на паўнату. Тут я апішу толькі агульныя прынцыпы і спынюся на некаторых распаўсюджаных праблемах, якія даводзіцца вырашаць.
Набор дакументаў
Пачнём з прыкладу.
Ніжэй прыведзены некаторыя дакументы, якія прынята ствараць у кампаніі Cisco Systems пры праектаванні.
CR – Сustomer Requirements, патрабаванні кліента (тэх. заданне).
Ствараецца сумесна з заказчыкам і вызначае патрабаванні да сеткі.HLD - High Level Design, высокаўзроўневы дызайн на аснове патрабаванняў да сеткі (CR). Дакумент тлумачыць і абгрунтоўвае прынятыя архітэктурныя рашэнні (тапалогія, пратаколы, выбар абсталявання,…). HLD не змяшчае дэталяў дызайну, напрыклад, аб выкарыстоўваных інтэрфейсах і IP-адрасах. Таксама тут не абмяркоўваецца канкрэтная канфігурацыя абсталявання. Гэты дакумент хутчэй прызначаны для тлумачэння тэхнічнаму мэнэджменту замоўца ключавых канцэпцыі дызайну.
LLD – Low Level Design, нізкаўзроўневы дызайн на аснове высокаўзроўневага (HLD).
Ён павінен змяшчаць усе дэталі, неабходныя для рэалізацыі праекта, такія як, інфармацыя аб тым, як падключыць і наладзіць абсталяванне. Гэта поўнае кіраўніцтва па рэалізацыі дызайну. Гэты дакумент павінен прадастаўляць дастатковую інфармацыю для яго рэалізацыі нават не вельмі кваліфікаваным персаналам.Нешта, напрыклад, IP-адрасы, нумары AS, схема фізічнай камутацыі (cabling), можа быць "вынесена" у асобныя дакументы, такія як NIP (Network Implementation Plan).
Пабудова сеткі пачынаецца пасля стварэння гэтых дакументаў і адбываецца ў строгай адпаведнасці з імі і затым правяраецца замоўцам (тэсты) на адпаведнасць з дызайнам.
Вядома, у розных інтэгратараў, у розных кліентаў, у розных краінах патрабаванні да праектнай дакументацыі могуць быць розныя. Але хацелася б пазбегнуць фармальнасцей і разгледзець пытанне па сутнасці. Гэты этап - не аб праектаванні, а аб навядзенні парадку і нам патрэбен дастатковы для выканання нашых задач набор дакументаў (схем, табліц, апісанняў ...).
І на мой погляд, існуе нейкі абсалютны мінімум, без якога немагчыма эфектыўна кантраляваць сетку.
Гэта наступныя дакументы:
- схема (часопіс) фізічнай камутацыі (cabling)
- схема ці схемы сеткі з істотнай L2/L3 інфармацыяй
Схема фізічнай камутацыі
У некаторых невялікіх кампаніях працы, звязаныя з усталёўкай абсталявання і фізічнай камутацыяй (cabling) знаходзяцца ў зоне адказнасці сеткавых інжынераў.
У гэтым выпадку задача збольшага рашаецца наступным падыходам.
- выкарыстоўвайце дэскрыпцыю на інтэрфейсе для апісання таго, што да яго падлучана
- адміністрацыйна выключыце (shutdown) усе непадключаныя парты сеткавага абсталявання
Гэта дасць вам магчымасць, нават у выпадку праблемы з лінкам (калі на гэтым інтэрфейсе не працуе cdp ці lldp), хутка вызначыць, што падлучана да гэтага порта.
Гэтак жа вы лёгка зможаце ўбачыць якія парты ў вас занятыя, а якія вольныя, што неабходна для планавання падлучэнняў новага сеткавага абсталявання, сервераў ці працоўных станцый.
Але зразумела, што калі вы страціце доступ да абсталявання, тыя вы страціце і доступ да гэтай інфармацыі. Да таго ж такім чынам вы не зможаце запратакаляваць такую важную інфармацыю як што за абсталяванне, з якой спажыванай магутнасцю, з якой колькасцю партоў, у якой стойцы знаходзіцца, якія там патч-панэлі і куды (у якую стойку/патч-панэль) яны скамутаваны . Таму ўсё ж дадатковае дакументаванне (не толькі дэскрыпцыі на абсталяванні) вельмі карыснае.
Ідэальным варыянтам з'яўляецца выкарыстанне дадаткаў, створаных для працы з падобнага роду інфармацыяй. Але можна абмежавацца і простымі табліцамі (напрыклад, у Excel) ці адлюстраваць інфармацыю, якую вы лічыце неабходнай у L1/L2 схемах.
Важна!
Сеткавай інжынер, вядома, можа досыць добра ведаць тонкасці і стандарты СКС, тыпы стоек, тыпы крыніц бесперабойнага сілкавання, што такое халодны і гарачы калідор, рабіць правільнае зазямленне,… гэтак жа як у прынцыпе ён можа ведаць фізіку элементарных часціц або C++. Але трэба разумець усё ж, што ўсё гэта не з'яўляецца яго вобласцю ведаў.
Таму добрай практыкай з'яўляецца для рашэння задач злучаных з усталёўкай, падлучэннем, падтрымкай працаздольнасці абсталявання, а гэтак жа фізічнай камутацыяй мець ці вылучаныя аддзелы ці вылучаных людзей. Звычайна для дата-цэнтраў гэта дата-цэнтр інжынеры, а для офіса - help-desk.
Калі такія падраздзяленні прадугледжаны ў вашай кампаніі, то пытанні вядзення часопіса фізічнай камутацыі не з'яўляюцца вашай задачай, і вы можаце абмежавацца толькі дэскрыпцыяй на інтэрфейсе і адміністрацыйным выключэннем не выкарыстоўваных партоў.
Схемы сеткі
Няма ўніверсальнага падыходу да малявання схем.
Самае важнае - схемы павінны даваць разуменне таго, як будзе хадзіць трафік, праз якія лагічныя і фізічныя элементы вашай сеткі.
Пад фізічнымі элементамі мы маем на ўвазе
- актыўнае абсталяванне
- інтэрфейсы/парты актыўнага абсталявання
Пад лагічнымі -
- лагічныя прылады (N7K VDC, Palo Alto VSYS, …)
- VRF
- віланы
- сабітэрфейсы
- тунэлі
- зоны
- ...
Таксама, калі ваша сетка не з'яўляецца зусім элементарнай, яна будзе складацца з розных сегментаў.
Напрыклад
- дата-цэнтр
- інтэрнэт
- WAN
- аддалены доступ
- офісная LAN
- ДМЗ
- ...
Разумна будзе мець некалькі схем, якія даюць як агульную карціну (як трафік ходзіць паміж усімі гэтымі сегментамі), так і падрабязнае тлумачэнне кожнага асобнага сегмента.
Т. к. у сучасных сетках можа быць шмат лагічных узроўняў, то магчыма, добрым (але не абавязковым) падыходам з'яўляецца рабіць розныя схемы для розных узроўняў, напрыклад, у выпадку оверлейного падыходу гэта могуць бы наступныя схемы:
- накладанне
- L1/L2 underlay
- L3 underlay
Вядома, найважнейшай схемай, без якой немагчыма зразумець ідэю вашага дызайну з'яўляецца схема маршрутызацыі.
Схема маршрутызацыі
Як мінімум на гэтай схеме павінна быць адлюстравана
- якія пратаколы маршрутызацыі і дзе выкарыстоўваюцца
- асноўная інфармацыя аб настройках пратакола маршрутызацыі (area/AS number/router-id/…)
- на якіх прыладах адбываецца рэдыстрыбуцыя
- дзе адбываецца фільтраванне і агрэгацыя маршрутаў
- інфармацыя аб дэфолтным маршруце
Таксама часта карыснай з'яўляецца L2 схема (OSI).
L2 схема (OSI)
На гэтай схеме можа быць адлюстравана наступная інфармацыя:
- якія VLAN
- якія парты з'яўляюцца trunk партамі
- якія парты агрэгаваныя ў ether-channel (port channel), virtual port channel
- якія STP пратаколы і на якіх прыладах выкарыстоўваюцца
- асноўныя наладкі STP: root/root backup, STP cost, port priority
- дадатковыя наладкі STP: BPDU guard/filter, root guard…
Характэрныя памылкі пры праектаванні
Прыклад дрэннага падыходу да пабудовы сеткі.
Давайце возьмем просты прыклад пабудовы простай офіснай лакальнай сеткі.
Маючы досвед выкладання тэлекома студэнтам, магу сказаць, што фактычна любы студэнт да сярэдзіны другога семестра валодае неабходным веданнем (у рамках курса, які вёў я) для таго каб наладзіць простую офісную LAN.
Што складанага ў тым, каб падлучыць сябар да сябра камутатары, наладзіць VLAN, SVI інтэрфейсы (у выпадку L3 камутатараў) і прапісаць статычны роўтынг?
Усё будзе працаваць.
Але пры гэтым застаюцца ўбаку пытанні, звязаныя з
- бяспекай
- рэзерваваннем
- маштабаваннем сеткі
- прадукцыйнасцю
- прапускной здольнасцю
- надзейнасцю
- ...
Часам я чую сцвярджэнне, што офісная LAN – гэта нешта вельмі простае і чую гэта звычайна ад інжынераў (і менеджэраў), якія займаюцца ўсім чым заўгодна, але толькі не сеткамі, і кажуць яны гэта настолькі ўпэўнена, што не дзіўцеся, калі LAN будзе зроблена людзьмі з недастатковай практыкай і ведамі і будзе зроблена прыблізна з тымі памылкамі, якія я апішу крыху ніжэй.
Характэрныя памылкі дызайну ўзроўню L1 (OSI)
- Калі ўсё ж вы адказваеце ў тым ліку і за СКС, то адной з самых непрыемных спадчын, якая вам можа дастацца - гэта нядбайная і не прадуманая камутацыя.
Гэтак жа да тыпу L1 я б аднёс памылкі, злучаныя з рэсурсамі выкарыстоўванага абсталявання, напрыклад,
- недастатковая паласа прапускання
- недастатковы TCAM на абсталяванні (ці неэфектыўнае яго выкарыстанне)
- недастатковая прадукцыйнасць (часта ставіцца да фаервалаў)
Характэрныя памылкі дызайну ўзроўню L2 (OSI)
Часта, калі няма добрага разумення, як працуе STP, якія патэнцыйныя праблемы ён нясе з сабой, камутатары падключаюцца хаатычна, з наладамі па змаўчанні, без дадатковага цюнінгу STP.
У выніку часта маем наступнае
- вялікі STP дыяметр сеткі, што можа прыводзіць да бродкастных штармоў
- STP root будуць вызначаны выпадкова (на аснове mac адраса) і шлях трафіку будзе неаптымальным
- парты, якія падключаюцца да хастаў, не будуць настроены як edge (portfast), што прывядзе да пераліку STP пры ўключэнні/выключэнні канчатковых станцый
- сетка не будзе сегментаваць на ўзроўні L1/L2, у выніку чаго праблемы з любым камутатарам (напрыклад, перагрузка па сілкаванні) будзе прыводзіць да пераліку STP тапалогіі і прыпынку трафіку ва ўсіх VLAN на ўсіх камутатарах (у тым ліку і ў крытычным з пункта гледжання бесперапыннасці сэрвісу сегменце)
Прыклады памылак у праектаванні L3 (OSI)
Некалькі характэрных памылак пачаткоўцаў сецявікоў:
- частае выкарыстанне (ці выкарыстанне толькі) статычнага роўтынгу
- выкарыстанне неаптымальных для дадзенага дызайну пратаколаў маршрутызацыі
- неаптымальная лагічная сегментацыя сеткі
- неаптымальнае выкарыстанне адраснай прасторы, што не дазваляе праводзіць агрэгаванне маршрутаў
- адсутнасць рэзервовых маршрутаў
- адсутнасць рэзервавання для default gateway
- асіметрычны роўтынг пры перастраенні маршрутаў (можа быць крытычным у выпадку NAT/PAT, statefull firewalls)
- праблемы з MTU
- пры перабудове маршрутаў трафік ідзе праз іншыя security зоны ці нават іншыя фаервалы, што прыводзіць да таго, што гэты трафік драпаецца
- дрэнная маштабаванасць тапалогіі
Крытэры адзнакі якасці дызайну
Калі мы гаворым пра аптымальнасць/не аптымальнасць, мы павінны разумець з пункту гледжання якіх крытэрыяў мы можам ацаніць гэта. Вось з майго пункту гледжання найбольш істотныя (але не ўсе) крытэрыі (і расшыфроўка ў дачыненні да пратаколаў маршрутызацыі):
- маштабаванасць ( scalability)
Напрыклад, вы вырашылі дадаць яшчэ адзін дата-цэнтр. Наколькі лёгка вы гэта можаце зрабіць. - зручнасць ва ўпраўленні (managability)
Наколькі лёгка і бяспечна робяцца аперацыйныя змены, напрыклад, анансаванне новай сеткі ці фільтраванне маршрутаў - даступнасць (availability)
Які працэнт часу ваша сістэма дае патрабаваны ўзровень сэрвісу - бяспека (security)
Наколькі абаронены перадаюцца дадзеныя - кошт
Змены
Асноўны прынцып на дадзеным этапе можна выказаць формулай "не нашкодзь".
Таму, нават калі вы не зусім згодны з дызайнам, і абранай рэалізацыяй (канфігурацыяй), тое не заўсёды мэтазгодна рабіць змены. Разумным падыходам з'яўляецца ранжыраванне ўсіх выяўленых праблем па двух параметрах:
- наколькі лёгка гэта праблема можа быць выпраўлена
- наколькі вялікую рызыку яна нясе
Першым чынам трэба ўхіліць тое, што ў цяперашнім часе змяншае ўзровень які прадстаўляецца сэрвісу ніжэй дапушчальнага, напрыклад, праблемы, якія прыводзяць да страт пакетаў. Затым ухіляйце тое, што лягчэй за ўсё і бяспечней ухіліць у парадку памяншэння сур'ёзнасці рызыкі (ад праблем у дызайне ці канфігурацыі, якія нясуць вялікія рызыкі ў бок малодшых).
Перфекцыянізм на дадзеным этапе можа быць шкодны. Прывядзіце дызайн да здавальняючага стану і сінхранізуйце канфігурацыю сеткі ў адпаведнасці з ім.
Крыніца: habr.com