Оваа статија е втора од серијата написи „Како да ја преземете контролата врз вашата мрежна инфраструктура“. Содржината на сите написи во серијата и линковите може да се најдат .
Нашата цел во оваа фаза е да воведеме ред во документацијата и конфигурацијата.
На крајот од овој процес, треба да го имате потребниот сет на документи и мрежата конфигурирана во согласност со нив.
Сега нема да зборуваме за безбедносни ревизии - ова ќе биде тема на третиот дел.
Тешкотијата за завршување на задачата доделена во оваа фаза, се разбира, многу варира од компанија до компанија.
Идеална ситуација е кога
- вашата мрежа е создадена во согласност со проектот и имате комплетен сет на документи
- е имплементиран во вашата компанија за мрежа
- во согласност со овој процес, имате документи (вклучувајќи ги сите потребни дијаграми) кои даваат целосни информации за моменталната состојба на работите
Во овој случај, вашата задача е прилично едноставна. Треба да ги проучите документите и да ги прегледате сите промени што се направени.
Во најлошото сценарио, ќе имате
- мрежа создадена без проект, без план, без одобрение, од инженери кои немаат доволно ниво на квалификации,
- со хаотични, недокументирани промени, со многу „ѓубре“ и неоптимални решенија
Јасно е дека вашата ситуација е некаде помеѓу, но за жал, на оваа скала подобро - полошо, постои голема веројатност дека ќе бидете поблиску до најлошиот крај.
Во овој случај, ќе ви треба и способност да читате мисли, бидејќи ќе треба да научите да разберете што сакале да направат „дизајнерите“, да ја вратите нивната логика, да го завршите она што не е завршено и да го отстраните „ѓубрето“.
И, се разбира, ќе треба да ги поправите нивните грешки, да го промените (во оваа фаза колку што е можно минимално) дизајнот и да ги промените или повторно да ги креирате шемите.
Оваа статија во никој случај не тврди дека е целосна. Овде ќе ги опишам само општите принципи и ќе се фокусирам на некои заеднички проблеми што треба да се решат.
Збир на документи
Да почнеме со пример.
Подолу се дадени неколку документи кои вообичаено се креираат во Cisco Systems за време на дизајнот.
CR – Барања на клиентите, барања на клиентите (технички спецификации).
Се создава заедно со клиентот и ги одредува мрежните барања.HLD – Дизајн на високо ниво, дизајн на високо ниво заснован на мрежни барања (CR). Документот ги објаснува и оправдува донесените архитектонски одлуки (топологија, протоколи, избор на хардвер,...). HLD не содржи детали за дизајнот, како што се користените интерфејси и IP адреси. Исто така, специфичната хардверска конфигурација не се дискутира овде. Наместо тоа, овој документ е наменет да ги објасни клучните концепти за дизајн на техничкиот менаџмент на клиентот.
LLD – Дизајн на ниско ниво, дизајн на ниско ниво заснован на дизајн на високо ниво (HLD).
Треба да ги содржи сите детали потребни за спроведување на проектот, како што се информации за тоа како да се поврзе и конфигурира опремата. Ова е целосен водич за спроведување на дизајнот. Овој документ треба да обезбеди доволно информации за негово спроведување дури и од помалку квалификуван персонал.Нешто, на пример, IP адреси, AS броеви, шема за физичко префрлување (каблирање), може да се „издадат“ во посебни документи, како на пр. НИП (План за имплементација на мрежата).
Изградбата на мрежата започнува по креирањето на овие документи и се случува во строга согласност со нив и потоа се проверува од страна на клиентот (тестови) за усогласеност со дизајнот.
Се разбира, различни интегратори, различни клиенти и различни земји може да имаат различни барања за проектна документација. Но, би сакал да избегнам формалности и да го разгледам прашањето според неговата основа. Оваа фаза не е за дизајнирање, туку за поставување на работите во ред и ни треба доволен сет на документи (дијаграми, табели, описи...) за да ги завршиме нашите задачи.
И според мое мислење, постои одреден апсолутен минимум, без кој е невозможно ефективно да се контролира мрежата.
Ова се следните документи:
- дијаграм (дневник) на физичко префрлување (каблирање)
- мрежен дијаграм или дијаграми со суштински информации за L2/L3
Дијаграм за физичко префрлување
Во некои мали компании, работата поврзана со инсталација на опрема и физичко префрлување (каблирање) е одговорност на мрежните инженери.
Во овој случај, проблемот е делумно решен со следниот пристап.
- користете опис на интерфејсот за да опишете што е поврзано со него
- административно исклучување на сите неповрзани порти за мрежна опрема
Ова ќе ви даде можност, дури и во случај на проблем со врската (кога cdp или lldp не работат на овој интерфејс), брзо да одредите што е поврзано со оваа порта.
Можете исто така лесно да видите кои порти се окупирани, а кои се бесплатни, што е неопходно за планирање на поврзувања на нова мрежна опрема, сервери или работни станици.
Но, јасно е дека ако го изгубите пристапот до опремата, ќе го изгубите и пристапот до овие информации. Дополнително, на овој начин нема да можете да снимите толку важни информации како што се опремата, каква потрошувачка на енергија, колку порти, во која решетка се наоѓа, какви печ-панели има и каде (во кој rack/patch panel ) тие се поврзани . Затоа, дополнителната документација (не само описи на опремата) е сè уште многу корисна.
Идеалната опција е да користите апликации дизајнирани да работат со овој тип на информации. Но, можете да се ограничите на едноставни табели (на пример, во Excel) или да ги прикажете информациите што ги сметате за неопходни во дијаграмите L1/L2.
Важно!
Мрежен инженер, се разбира, може доста добро да ги знае сложеноста и стандардите на SCS, видовите на лавици, видовите на непрекинато напојување, што е ладен и топол ходник, како да прави правилно заземјување... исто како што во принцип може ја знае физиката на елементарните честички или C++. Но, сепак мора да се разбере дека сето ова не е негова област на знаење.
Затоа, добра практика е да има или посветени одделенија или посветени луѓе за решавање на проблеми поврзани со инсталација, поврзување, одржување на опремата, како и физичко префрлување. Вообичаено за центрите за податоци ова се инженери на центри за податоци, а за канцеларија тоа е Help-desk.
Ако таквите поделби се обезбедени во вашата компанија, тогаш проблемите со физичкото префрлување на евиденција не се ваша задача и можете да се ограничите само на опис на интерфејсот и административно исклучување на неискористените порти.
Мрежни дијаграми
Не постои универзален пристап за цртање дијаграми.
Најважно е дека дијаграмите треба да обезбедат разбирање за тоа како ќе тече сообраќајот, низ кои логички и физички елементи на вашата мрежа.
Под физички елементи подразбираме
- активна опрема
- интерфејси/порти на активна опрема
Под логично -
- логички уреди (N7K VDC, Palo Alto VSYS, ...)
- VRF
- Вилани
- потинтерфејси
- тунели
- зона
- ...
Исто така, ако вашата мрежа не е целосно елементарна, таа ќе се состои од различни сегменти.
На пример
- на Центарот за податоци
- Интернет
- WAN
- Далечински пристап
- канцелариски LAN
- DMZ
- ...
Паметно е да имате неколку дијаграми кои ја даваат и големата слика (како сообраќајот тече помеѓу сите овие сегменти) и детално објаснување за секој поединечен сегмент.
Бидејќи во современите мрежи може да има многу логички слоеви, можеби е добар (но не и неопходен) пристап да се направат различни кола за различни слоеви, на пример, во случај на преклопен пристап, ова може да бидат следниве кола:
- шалче
- L1/L2 подлога
- L3 подлога
Се разбира, најважниот дијаграм, без кој е невозможно да се разбере идејата за вашиот дизајн, е дијаграмот за насочување.
Шема за рутирање
Во најмала рака, овој дијаграм треба да се одразува
- кои протоколи за рутирање се користат и каде
- основни информации за поставките на протоколот за насочување (област/број АС/идентичен со рутер/…)
- на кои уреди се врши прераспределба?
- каде што се случува филтрирање и агрегација на рути
- стандардни информации за маршрутата
Исто така, шемата L2 (OSI) често е корисна.
L2 шема (OSI)
Овој дијаграм може да ги прикаже следниве информации:
- какви VLAN-ови
- кои пристаништа се пристаништа на багажникот
- кои порти се собираат во етер-канал (канал на пристаниште), канал на виртуелна порта
- кои STP протоколи се користат и на кои уреди
- основни поставки на STP: резервна копија на root/root, цена на STP, приоритет на порта
- дополнителни поставки STP: BPDU чувар/филтер, root guard…
Типични грешки во дизајнот
Пример за лош пристап за градење мрежа.
Да земеме едноставен пример за изградба на едноставна канцелариска 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
- кога маршрутите се обновуваат, сообраќајот оди преку други безбедносни зони или дури и други заштитни ѕидови, што доведува до откажување на овој сообраќај
- слаба топологија приспособливост
Критериуми за оценување на квалитетот на дизајнот
Кога зборуваме за оптималност/неоптималност, мора да разбереме од гледна точка на кои критериуми можеме да го оцениме ова. Еве, од моја гледна точка, најзначајните (но не сите) критериуми (и објаснување во однос на протоколите за рутирање):
- приспособливост
На пример, одлучувате да додадете друг центар за податоци. Колку лесно можете да го направите тоа? - леснотија на користење (управливост)
Колку се лесни и безбедни оперативните промени, како што се објавување нова мрежа или филтрирање на рути? - достапност
Колкав процент од времето го обезбедува вашиот систем потребното ниво на услуга? - безбедност
Колку се безбедни пренесените податоци? - цена
Промени
Основниот принцип во оваа фаза може да се изрази со формулата „не прави штета“.
Затоа, дури и ако не се согласувате целосно со дизајнот и избраната имплементација (конфигурација), не е секогаш препорачливо да се прават промени. Разумен пристап е да се рангираат сите идентификувани проблеми според два параметри:
- колку лесно може да се реши овој проблем
- колку ризик носи таа?
Пред сè, неопходно е да се елиминира она што моментално го намалува нивото на обезбедената услуга под прифатливото ниво, на пример, проблемите што доведуваат до губење на пакети. Потоа поправете го она што е најлесно и најбезбедно за поправање по опаѓачки редослед на сериозноста на ризикот (од проблеми со дизајнот или конфигурацијата со висок ризик до оние со низок ризик).
Перфекционизмот во оваа фаза може да биде штетен. Доведете го дизајнот во задоволителна состојба и соодветно синхронизирајте ја конфигурацијата на мрежата.
Извор: www.habr.com