Система за мониторинг на ресурси и услуги на локална компютърна мрежа. Най-новото допълнение към функционалността на SNMP е спецификацията RMON, която позволява дистанционно взаимодействие с MIB. § Пълно описание на всички етапи на проектиране

Мониторинг и анализ на мрежата

Необходим е постоянен мониторинг на мрежата, за да се поддържа в изправност. Контролът е необходимата първа стъпка, която трябва да се извърши при управление на мрежа. Този процес на работа на мрежата обикновено се разделя на 2 етапа: мониторинг и анализ.

На етапа на наблюдение, по-прост процедура - процедурасъбиране на първични данни за работата на мрежата: статистика за броя на фреймовете и пакетите от различни протоколи, циркулиращи в мрежата, състоянието на портовете на хъбове, комутатори и рутери и др.

След това се извършва етапът на анализ, който се разбира като по-сложен и интелектуален процес на разбиране на информацията, събрана на етапа на мониторинг, сравняването й с данни, получени по-рано, и разработване на предположения за възможни причинибавна или ненадеждна работа на мрежата.

Инструментите за наблюдение на мрежа и откриване на тесни места в нейната работа могат да бъдат разделени на два основни класа:

• стратегически;

• тактически.

Целта на стратегическите инструменти е да наблюдават широк спектър от работни параметри на цялата мрежа и да решават проблеми с конфигурацията на LAN.

Целта на тактическите средства е да наблюдават и отстраняват неизправности в мрежовите устройства и мрежовите кабели.

Стратегическите средства включват:

• системи за управление на мрежата

• вградени диагностични системи

• разпределени системи за мониторинг

• диагностични инструменти за операционни системи, работещи на големи машини и сървъри.

Най-пълният контрол върху работата се осъществява от системи за управление на мрежата, разработени от компании като DEC, Hewlett-Packard, IBM и AT&T. Тези системи обикновено се базират на отделен компютър и включват системи за управление на работни станции, кабелни системи, свързващи и други устройства, база данни, съдържаща параметри за управление на мрежи от различни стандарти, както и разнообразна техническа документация.

Една от най-добрите разработки за управление на мрежата, позволяваща на мрежовия администратор да получи достъп до всички нейни елементи, до работна станция, е пакетът LANDesk Manager на Intel, който осигурява мониторинг на приложения, инвентаризация на хардуера и софтуера и защита от вируси с помощта на различни инструменти. Този пакет предоставя в реално време разнообразна информация за приложни програми и сървъри, данни за мрежовата активност на потребителите.

Вградената диагностика се е превърнала в обичаен компонент на мрежови устройства като мостове, повторители и модеми. Примери за такива системи са пакетите Open - View Bridge Manager от Hewlett-Packard и Remote Bridge Management Software от DEC. За съжаление повечето от тях са фокусирани върху оборудване от един производител и са практически несъвместими с оборудване от други компании.

Разпределените системи за наблюдение са специални устройства, инсталирани на мрежови сегменти и предназначени да получават изчерпателна информация за трафика, както и за прекъсвания в работата на мрежата. Тези устройства, обикновено свързани към работната станция на администратора, се използват предимно в многосегментни мрежи.

Тактическите средства включват различни видовеустройства за тестване (тестери и скенери за мрежови кабели), както и устройства за цялостен анализ на работата на мрежата - анализатори на протоколи. Устройствата за тестване помагат на администратора да открие грешки в мрежовия кабел и конекторите, а анализаторите на протоколи помагат да се получи информация за обмена на данни в мрежата. В допълнение, тази категория инструменти включва специален софтуер, който ви позволява да получавате подробни отчети за състоянието на мрежата в реално време.

Инструменти за мониторинг и анализ

Класификация

Разнообразието от инструменти, използвани за наблюдение и анализ на компютърни мрежи, може да бъде разделено на няколко големи класа:

Системи за управление на мрежата(NetworkManagementSystems) - централизирани софтуерни системи, които събират данни за състоянието на мрежовите възли и комуникационните устройства, както и данни за трафика, циркулиращ в мрежата. Тези системи не само наблюдават и анализират мрежата, но и извършват действия по управление на мрежата в автоматичен или полуавтоматичен режим - активиране и дезактивиране на портове на устройства, промяна на параметрите на мостове, адресни таблици на мостове, комутатори и рутери и др. Примери за системи за управление включват популярни системи HPOpenView, SunNetManager, IBMNetView.

Системни контроли(Управление на системата). Системните контроли често изпълняват функции, подобни на тези на контролните системи, но по отношение на различни обекти. В първия случай обектът на управление е софтуер и Хардуермрежови компютри, а във втория - комуникационно оборудване. В същото време някои функции на тези два типа системи за управление могат да бъдат дублирани; например инструментите за управление на системата могат да извършват прост анализ на мрежовия трафик.

Вградени системи за диагностика и контрол(Вградени системи). Тези системи се реализират под формата на софтуерни и хардуерни модули, инсталирани в комуникационно оборудване, както и под формата на софтуерни модули, вградени в операционни системи. Те изпълняват диагностичните и контролните функции само на едно устройство и това е основната им разлика от централизираните системи за управление. Пример за инструменти от този клас е модулът за управление на хъба Distrebuted 5000, който изпълнява функциите за автоматично сегментиране на портове при откриване на неизправности, присвояване на портове към вътрешни сегменти на хъба и някои други. По правило вградените модули за управление се удвояват като SNMP агенти, които доставят данни за състоянието на устройството към системите за управление.

Анализатори на протоколи(Протокоанализатори). Те са софтуерни или хардуерно-софтуерни системи, които за разлика от системите за управление са ограничени само до функциите за наблюдение и анализ на трафика в мрежите. Един добър анализатор на протоколи може да улавя и декодира пакети от голям брой протоколи, използвани в мрежите - обикновено няколко десетки. Анализаторите на протоколи ви позволяват да зададете някои логически условия за улавяне на отделни пакети и да извършите пълно декодиране на уловените пакети, т.е. те показват във форма, удобна за специалист, влагането на протоколни пакети от различни нива един в друг с декодиране на съдържанието на отделни полета на всеки пакет.

д експертни системи. Този тип система акумулира знанията на техническите специалисти за идентифициране на причините за ненормална работа на мрежите и възможните начини за привеждане на мрежите в работно състояние. Експертните системи често се реализират като отделни подсистеми на различни инструменти за наблюдение и анализ на мрежата: системи за управление на мрежата, анализатори на протоколи, мрежови анализатори. Най-простата версия на експертна система е контекстно-чувствителна помощна система. По-сложните експертни системи са така наречените бази от знания, които имат елементи изкуствен интелект. Пример за такава система е експертната система, вградена в системата за управление Spectrum на Cabletron.

Оборудване за диагностика и сертификация на кабелни системи. Условно това оборудване може да се раздели на четири основни групи: мрежови монитори, устройства за сертификация на кабелни системи, кабелни скенери и тестери (мултиметри).

Мрежови монитори(наричани още мрежови анализатори) са предназначени за тестване на кабели от различни категории. Трябва да се прави разлика между мрежови монитори и анализатори на протоколи. Мрежовите монитори събират данни само по статистически показатели за трафик - средната интензивност на общия мрежов трафик, средната интензивност на потока от пакети с определен тип грешка и др.

Предназначение на устройствата за сертифициране на кабелни системи, следва директно от името им. Сертификацията се извършва в съответствие с изискванията на един от международните стандарти за кабелни системи.

Кабелни скенериизползва се за диагностика на медни кабелни системи.

Тестерите са проектираниза проверка на кабелите за физически прекъсвания.

Многофункционални апарати за анализ и диагностика. През последните години, поради повсеместното разпространение на локалните мрежи, имаше нужда от разработване на евтини преносими устройства, които комбинират функциите на няколко устройства: анализатори на протоколи, кабелни скенери и дори някои възможности на софтуер за управление на мрежата. Пример за такъв тип устройство е Compas от Microtest Inc. или 675 LANMeter от FlukeCorp.

Анализатори на протоколи

Когато проектирате нова или надграждате стара мрежа, често има нужда от количествено измерваненякои характеристики на мрежата, като например интензивността на потоците от данни по мрежовите комуникационни линии, закъсненията, които възникват на различни етапи от обработката на пакети, времето за отговор на заявки от един или друг тип, честотата на възникване на определени събития и други характеристики.

За тези цели могат да се използват различни инструменти и преди всичко инструменти за наблюдение в системите за управление на мрежата, които вече бяха обсъдени в предишните раздели. Някои мрежови измервания могат да се извършват и със софтуерни измервателни уреди, вградени в операционната система; пример за това е компонентът на Windows NTPerformanceMonitor. Дори съвременните кабелни тестери са способни да улавят пакети и да анализират тяхното съдържание.

Но най-модерният инструмент за изследване на мрежата е анализатор на протоколи. Процесът на анализ на протокола включва улавяне на пакети, циркулиращи в мрежа, които прилагат конкретен мрежов протокол, и изучаване на съдържанието на тези пакети. Въз основа на резултатите от анализа е възможно да се направят разумни и балансирани промени във всеки мрежов компонент, да се оптимизира неговата производителност и да се отстранят проблеми. Очевидно, за да се направят каквито и да било заключения относно въздействието на промяната върху мрежата, е необходимо да се анализират протоколите както преди, така и след извършването на промяната.

Анализаторът на протоколи е независимо специализирано устройство или персонален компютър, обикновено преносим, ​​от клас Notebook, оборудван със специална мрежова карта и подходящ софтуер. Използваната мрежова карта и софтуер трябва да отговарят на мрежовата топология (пръстен, шина, звезда). Анализаторът се свързва към мрежата по същия начин като обикновен възел. Разликата е, че анализаторът може да получи всички пакети данни, предадени по мрежата, докато обикновената станция може да получи само тези, адресирани до нея. Софтуерът на анализатора се състои от ядро, което поддържа работата на мрежовия адаптер и декодира получените данни, и допълнителен програмен код, в зависимост от вида на топологията на изследваната мрежа. Освен това се доставят редица специфични за протокола процедури за декодиране, като IPX. Някои анализатори могат също да включват експертна система, която може да предостави на потребителя препоръки за това какви експерименти трябва да се извършат в дадена ситуация, какво могат да означават определени резултати от измерване и как да се елиминират определени видове мрежови повреди.

Въпреки относителното разнообразие от анализатори на протоколи на пазара, има някои характеристики, които са общи за всички тях в една или друга степен:

• Потребителски интерфейс. Повечето анализатори имат разработен удобен за потребителя интерфейс, обикновено базиран на Windows или Motif. Този интерфейс позволява на потребителя да: показва резултатите от анализа на интензивността на трафика; получавате моментална и средна статистическа оценка на производителността на мрежата; задайте определени събития и критични ситуации, за да проследите тяхното възникване; декодиране на протоколи различни ниваи представя съдържанието на пакетите в разбираема форма.
• Буфер за улавяне. Буферите на различните анализатори се различават по размер. Буферът може да се намира на инсталираната мрежова карта или може да бъде отделено място за него оперативна паметедин от компютрите в мрежата. Ако буферът се намира на мрежовата карта, тогава той се управлява хардуерно и поради това скоростта на въвеждане се увеличава. Това обаче оскъпява анализатора. Ако изпълнението на процедурата за улавяне е недостатъчно, част от информацията ще бъде загубена и анализът ще бъде невъзможен. Размерът на буфера определя възможностите за анализ на повече или по-малко представителни проби от уловените данни. Но колкото и голям да е буферът за улавяне, рано или късно той ще се напълни. В този случай или прихващането спира, или пълненето започва от началото на буфера.
• Филтри. Филтрите ви позволяват да контролирате процеса на събиране на данни и по този начин спестявате буферно пространство. В зависимост от стойността на определени пакетни полета, зададени като условие за филтър, пакетът или се игнорира, или се записва в буфера за улавяне. Използването на филтри значително ускорява и опростява анализа, тъй като елиминира преглеждането на ненужни в момента пакети.
• Превключвателите са определени условия, определени от оператора за стартиране и спиране на процеса на прихващане на данни от мрежата. Такива условия могат да включват изпълнение на ръчни команди за стартиране и спиране на процеса на улавяне, час от деня, продължителност на процеса на улавяне и появата на определени стойности в кадри с данни. Превключвателите могат да се използват заедно с филтри, което позволява по-подробен и нюансиран анализ, както и по-продуктивно използване на ограниченото буферно пространство за улавяне.
• Търсене. Някои анализатори на протоколи ви позволяват да автоматизирате преглеждането на информация в буфера и да намирате данни в него въз основа на определени критерии. Докато филтрите проверяват входния поток, за да видят дали отговаря на условията на филтъра, функциите за търсене се прилагат към данните, които вече са натрупани в буфера.

Методологията на анализа може да бъде представена в следните шест етапа:

1. Улавяне на данни.
2. Преглед на заснетите данни.
3. Анализ на данни.
4. Откриване на грешки. (Повечето анализатори улесняват тази работа, като откриват типове грешки и идентифицират станцията, от която идва пакетът за грешка.)
5. Изследване на ефективността. Изчислява се степента на използване на честотната лента на мрежата или средното време за отговор на заявка.
6. Детайлно проучване на отделни участъци от мрежата. Съдържанието на този етап се уточнява с напредването на анализа.

Обикновено процесът на анализиране на протоколите отнема сравнително малко време - 1-2 работни дни.

Мрежови анализатори

Мрежовите анализатори (да не се бъркат с анализаторите на протоколи) са референтни инструменти за измерване за диагностика и сертифициране на кабели и кабелни системи. Пример са мрежовите анализатори на HewlettPackard - HP 4195A и HP 8510C.

Мрежовите анализатори съдържат високоточен честотен генератор и теснолентов приемник. Чрез предаване на сигнали с различни честоти в предавателната двойка и измерване на сигнала в приемащата двойка, затихването и NEXT могат да бъдат измерени. Мрежовите анализатори са прецизни, големи и скъпи (струващи над $20 000) инструменти, предназначени за използване в лабораторни условия от специално обучен технически персонал.

Кабелни скенери

Тези устройства ви позволяват да определите дължината на кабела, NEXT, затихване, импеданс, електрическа схема, ниво на електрически шум и да оцените резултатите. Цената на тези устройства варира от $1000 до $3000. Има доста устройства от този клас, например скенери от Microtest Inc., Fluke Corp., Datacom Technologies Inc., Scope Communication Inc. За разлика от мрежовите анализатори, скенерите могат да се използват не само от специално обучен технически персонал, но дори и от начинаещи администратори.

За да определите местоположението на повреда в кабелната система (счупване, късо съединение, неправилно инсталиран конектор и т.н.) се използва методът „кабелен радар“ или TimeDomainReflectometry (TDR). Същността на този метод е, че скенерът излъчва кратък електрически импулс в кабела и измерва времето на забавяне преди пристигането на отразения сигнал. Полярността на отразения импулс определя естеството на повредата на кабела (късо съединение или прекъсване). При правилно инсталиран и свързан кабел изобщо няма отразен импулс.

Точността на измерване на разстоянието зависи от това колко точно е известна скоростта на разпространение на електромагнитните вълни в кабела. Ще бъде различно за различните кабели. Скоростта на разпространение на електромагнитните вълни в кабел (NVP - номинална скорост на разпространение) обикновено се определя като процент от скоростта на светлината във вакуум. Съвременните скенери съдържат електронна таблица с данни за NVP за всички основни видове кабели и позволяват на потребителя сам да зададе тези параметри след предварително калибриране.

Най-известните производители на компактни (размерите им обикновено не надвишават размера на VHS видеокасета) кабелни скенери са MicrotestInc., WaveTekCorp., ScopeCommunicationInc.

Тестери

Тестерите за кабелни системи са най-простите и евтини устройства за диагностика на кабели. Те ви позволяват да определите непрекъснатостта на кабела, но за разлика от кабелните скенери, те не отговарят на въпроса къде е възникнала повредата.

Вградени инструменти за наблюдение и анализ на мрежата

SNMP агенти

Днес има няколко стандарта за бази данни с управленска информация. Основните са стандартите MIB-I и MIB-II, както и версията на базата данни за дистанционно управление RMONMIB. Освен това има стандарти за MIB за специфични устройства от конкретен тип (например MIB за хъбове или MIB за модеми), както и собствени MIB за специфични производители на оборудване.

Оригиналната MIB-I спецификация дефинира само операции за четене на стойности на променливи. Операциите за промяна или задаване на стойности на обекти са част от спецификациите на MIB-II.

27.06.2011 Нейт Макалмънд

Избрах трима кандидата: WhatsUp Gold Premium от Ipswitch, OpManager Professional от ManageEngine и ipMonitor от SolarWinds. Всеки от тези мрежови скенери струва по-малко от $3000 (за 100 устройства) и всеки идва с пробен период, през който можете да тествате продукта си безплатно

Работя за средно голяма компания и използваме една и съща система за наблюдение на мрежата от около седем години. Той предоставя на нашите администратори основна информация за наличността на сървъри и услуги, а също така изпраща SMS текстови съобщения до мобилните ни телефони в случай на проблеми. Стигнах до извода, че е необходимо да надградя системата или поне да добавя ефективен инструмент, който може да осигури по-добра производителност и да предостави подробна информация за изправността на терминалните сървъри, Exchange и SQL системите, хоствани във вашата мрежа. . Нека сравним нашите кандидати.

Процес на откриване

За да се подготвите за тестване, първата стъпка беше да активирате SNMP услугата на всички устройства, включително Windows сървъри. Променяйки настройките на услугата SNMP, задавам достъп само за четене до всички устройства, които трябва да бъдат обхванати от процеса на наблюдение. В системите Windows сървър 2003/2000 услугата SNMP се инсталира с помощта на съветника за компоненти на Windows, намиращ се в панела за добавяне/премахване на програми и в Windows система SNMP компонентите на Server 2008 се добавят с помощта на съветника за диспечера на сървъра. След като завършите съветника, трябва да стартирате модула за услуги, намиращ се в папката на контролния панел, и да конфигурирате услугата SNMP - това не е трудно. Управляваните мрежови устройства като защитни стени, комутатори, рутери и принтери също имат възможности за управление на SNMP услуги и процесът на настройка обикновено е доста проста операция. За повече информация относно услугата SNMP вижте документа Simple Network Management Protocol (technet.microsoft.com/en-us/library/bb726987.aspx).

След това инсталирах и трите системи за наблюдение на една от двете ми работещи системи с Windows XP SP3. Веднъж инсталирана, всяка система се състои от две части: база данни и уеб сървър. Всяка от избраните системи може да се управлява през уеб интерфейса от множество администратори, като имате възможност да настройвате акаунти с различни нива на достъп. Общото между трите системи е, че всеки потребител има възможността да добавя, изтрива и мести свои собствени панели работна среда. Панелите показват един и същи тип данни, като натоварване на процесора или използване на паметта за различни устройства в мрежата.

Преди да започна да сканирам мрежата (наречен процес на откриване), зададох параметрите сметка, който всяка система трябва да използва, за да получи достъп до устройства, открити в мрежата. Както е показано в таблицата за сравнение, Ipswitch WhatsUp Gold Premium ви позволява да конфигурирате акаунт за работа с услуги SNMP, WMI, Telnet, SSH, ADO и VMware. Системата ManageEngine OpManager Professional ви позволява да работите с помощта на протоколите SNMP, WMI, Telnet, SSH и URL, а системата SolarWinds ipMonitor ви позволява да работите с протоколите SNMP, WMI и URL.

След настройка на услугата SNMP на мрежови устройства и акаунти (Windows и SNMP) за всяка система наблюдение на мрежатаЗапочнах процеса на откриване за набор от IP адреси в моя локална мрежа. Всички системи откриха около 70 устройства. Използвайки настройките за сканиране по подразбиране, тестваните системи се представиха добре при идентифициране на типове устройства и също така предоставиха подробна информация за състоянието на устройствата. И трите системи съдържат сензори за ключови характеристики на производителността на устройства и сървъри, като: натоварване на процесора, използване на паметта, използване/пълност на диска, загуба на пакети/закъснение, състояние на услугите на Exchange, Lotus, Активна директорияи всички Windows услуги. Всяка от системите имаше възможност за добавяне на сензори както за отделни устройства, така и за големи групи от устройства.

Пакетите OpManager и WhatsUp Gold предоставят интерфейс за идентифициране и събиране на събития от услуги на VMware от сървъри и гости. Освен това и двата продукта включват функция за запитване на диспечера на портове за комутатори, която показва кои устройства са свързани към различни портове на управлявани комутатори. Получената информация може да ви помогне да определите кой порт на комутатора се свързва с конкретно бизнес приложение, без да е необходимо ръчно да проследявате кабелите в сървърните стаи. По-късно можете да конфигурирате предупреждения за конкретни портове на комутатора. Когато работите с пакета OpManager, за да получите резултати от търсенето на портове, просто изберете превключвателя и стартирайте инструмента Switch Port Mapper - системата ще върне резултатите след няколко секунди. Подобен инструмент, включен в WhatsUp Gold, се нарича MAC адрес и трябва да се стартира с отметната опция Get Connectivity. WhatsUp Gold отнема повече време, за да даде резултати, докато се опитва да сканира устройства и да събира информация за връзки в цялата мрежа.

Ipswitch WhatsUp Gold Premium

Ipswitch WhatsUp Gold Premium
ЗАД:предоставя най-точните резултати сред трима конкуренти, позволява ви да създавате свои собствени сензори, предоставя изчерпателни инструменти за наблюдение за системите на VMware и се интегрира с AD.
ПРОТИВ:по-малко вградени сензори и по-висока цена в сравнение с конкурентите (ако закупите лиценз за по-малко от 500 устройства).
ОЦЕНКА: 4,5 от 5.
ЦЕНА:$7495 за 500 устройства, $2695 за 100 устройства, $2195 за 25 устройства.
ПРЕПОРЪКИ: Препоръчвам WhatsUp Gold IT на отдели, работещи с големи VMware среди или желаещи да изградят свои собствени сензори.
ИНФОРМАЦИЯ ЗА ВРЪЗКА: Ipswitch, www.ipswitch.com

Когато работех със системите IpMonitor и OpManager, от време на време се натъквах на неразбираеми показания, които ме объркваха. В системата IpMonitor отрицателните стойности могат да се показват в операционните панели, когато нивото на натоварване на процесора спадна значително. В друг случай, когато натоварването на процесора беше близо до нула, системата IpMonitor ми изпрати известие, че процесорът е използван на 11,490%! Системата OpManager, докато наблюдаваше и ми изпращаше правилна информация за използването на диска от домейн контролери, в някои случаи не включи нито един от контролерите в списъка с 10 сървъра с максимално използване дисково пространство. В същото време съседният панел уведоми, че един от моите домейн контролери дори не трябва да е в първите десет, а в първите три. Не съм срещал подобни ситуации при използване на WhatsUp Gold. Системата WhatsUp Gold следи натоварването на процесорните ядра в своите панели и когато сравних резултатите от панелите WhatsUp Gold с показанията Windows инструменти Performance Monitor, съвпадаха точно за всяко ядро. По същия начин информацията за използването на твърдия диск беше правилно докладвана на всички съответни приложения за работно пространство.

Системата WhatsUp Gold има вградена сензорна библиотека, която ви позволява да създавате нови сензори на базата на съществуващи. Големите организации може да намерят тази функция полезна, тъй като им позволява да създадат единичен набор от сензори за наблюдение различни видовеУстройства е най-ефективният начин за конфигуриране на сензори за група устройства.

WhatsUp Gold няма сензори за отделни устройства (с изключение на сензора за APC UPS захранвания), за разлика от пакета OpManager, който използва собствени сензори за устройства на Dell, HP и IBM, но позволява създаването на сензори Active Script . Този видви позволява да разработите свои собствени процеси за наблюдение, като използвате езиците за програмиране VBScript и JScript. Онлайн център за поддръжка е посветен на сензорите на Active Script, където потребителите на WhatsUp Gold могат да получават и изтеглят готови скриптове.

Единственото подобрение, което бих искал да видя в WhatsUp Gold, е в интерфейса (Екран 1), главно защото е твърде линеен. Например ще отнеме до 5 щраквания върху бутоните Отказ и Затваряне, за да се върнете от прозореца на Active Monitor Library обратно в работната област. Освен това системата WhatsUp Gold няма сензор (освен ако, разбира се, не го напишете ръчно), който да проверява състоянието на сайта и може да се наложи, особено в случаите, когато сайтът се хоства на сървър на трета страна и няма други начини за достъп до него.

Екран 1: Интерфейс WhatsUp Gold Premium

За да се справите със ситуации, при които устройствата не работят за определен период от време, можете да конфигурирате известията да се изпращат на всеки 2, 5 или 20 минути. По този начин можете да привлечете вниманието на администратора към липсата на отговор от критични възли за определено време.

WhatsUp Gold е единствената от разглежданите системи, която има способността да се интегрира в LDAP среда - тази точка може да бъде фундаментална при избора на решение за големи мрежи.

ManageEngine OpManager

ManageEngine OpManager
ЗАД:най-добър потребителски интерфейс сред трите продукта; повече вградени сензори от другите две системи; повечето ниска ценапри закупуване на лиценз за 50 или по-малко устройства.
ПРОТИВ:по време на тестовете не всички индикатори на устройството се показват правилно; Може да се наложи да отделите време за отстраняване на грешки, за да стане системата напълно функционална.
ОЦЕНКА: 4,5 от 5.
ЦЕНА:$1995 за 100 устройства, $995 за 50 устройства, $595 за 25 устройства.
ПРЕПОРЪКИ:ИТ отдели, желаещи да получат максимална сумавградени възможности (с изключение на AD интеграция) ще оценят OpManager Professional. При закупуване на лицензи, вариращи от 26 до 50 устройства, цената е почти половината от цената на другите два продукта.
ИНФОРМАЦИЯ ЗА ВРЪЗКА: ManageEngine, www.manageengine.com

След като инсталирах системата OpManager, открих, че е лесно да конфигурирам огромен брой функции и лесно да навигирам между тях. OpManager предоставя възможност за изпращане (заедно с чрез имейли SMS) Директните съобщения за акаунт в Twitter са приятна алтернатива електронна поща. Използването на акаунти в Twitter по този начин ми позволява да бъда в крак със случващото се онлайн, но тъй като телефонът ми не звъни, когато се доставят съобщения от системата на Twitter, искам също да получавам текстови известия за най-важните събития. Мога да преглеждам прагове на всеки сървър чрез съобщения в Twitter и по този начин да имам регистър на текущите събития в мрежата, но не е задължително да използвам тази схема, за да съобщавам критични предупреждения.

В допълнение към стандартните сензори, OpManager предлага SNMP технологии за мониторинг на производителността, разработени от доставчици като Dell Power-Edge, HP Proliant и IBM Blade Center. OpManager също може да бъде интегриран с Google Maps API, за да можете да добавяте вашите устройства към картата на Google. Въпреки това ще трябва да закупите Google Maps API Premium акаунт, за да направите това (освен ако не планирате да направите мрежовата си карта публично достъпна), предмет на лицензионните условия на безплатната версия Google системи API за карти.

За да се справи със ситуации, при които администратор получава предупреждение, но не отговаря на него в рамките на определен период от време, OpManager може да бъде конфигуриран да изпраща допълнителен сигнал до друг администратор. Например, служител, който обикновено отговаря за обработката на критични събития за определена група сървъри, може да е зает или болен. В този случай има смисъл да настроите допълнителен сигнал, който да привлече вниманието на друг администратор, ако първият сигнал не е бил прегледан или изчистен в рамките на определен брой часове/минути.

Сред трите разглеждани продукта само системата OpManager имаше раздел, предназначен да следи качеството на VoIP обмена в глобалната мрежа. За да използвате инструменти за наблюдение на VoIP, устройствата както в изходната, така и в целевата мрежа трябва да поддържат технологията Cisco IP SLA. В допълнение, OpManager, показан на фигура 2, включва повече сензори и операционни панели от всеки конкурентен продукт.

Екран 2: Професионален интерфейс на OpManager

SolarWinds ipMonitor

SolarWinds ipMonitor
ЗАД:неограничен брой устройства на много ниска цена; лекота на използване.
ПРОТИВ:Няма механизъм за координиране на действията на администраторите.
ОЦЕНКА: 4 от 5.
ЦЕНА:$1995 - неограничен брой устройства (25 сензора безплатно).
ПРЕПОРЪКИ:ако бюджетът ви е ограничен и трябва да организирате наблюдение на голям брой устройства, ако процесът на наблюдение не изисква сложни решения и ви подхожда извънсистемен подход за координиране на действията на администраторите, системата SolarWinds е вашият избор .
ИНФОРМАЦИЯ ЗА ВРЪЗКА: SolarWinds, www.solarwinds.com

След първото ми запознанство със системата ipMonitor, нейният интерфейс, показан на фигура 3, ми се стори много объркващ. Отне ми почти цяла вечност да намеря мястото, където е конфигурирана честотата на системата, проверяваща отделните системни сензори (по подразбиране анкетата се извършва на всеки 300 секунди). Въпреки това, след като използвах ipMonitor в продължение на няколко седмици, установих, че системата е изключително лесна за използване и има достатъчно възможности за качествен мониторинг на мрежата. С ipMonitor можете да конфигурирате сканиране „по подразбиране“, така че всяка услуга или настройка за производителност винаги да бъдат включени в бъдещи сканирания. В допълнение към стандартните (и по-високи) сензори, системата ipMonitor предлага лог сензор Windows събития, който може да се използва за изпращане на предупреждения при откриване на критични събития.

Екран 3: SolarWinds ipMonitor интерфейс

От друга страна, системата ipMonitor няма механизми за проследяване/насочване на сигнали. Това може да няма значение, ако компанията има един мрежов администратор, но по-големите ИТ отдели вероятно ще намерят неспособността на системата да потвърждава предупреждения, да присвоява получатели и да нулира предупрежденията за значителен недостатък. Ако администраторите забравят да се координират извън системата, може да има ситуации, при които множество администратори получават едно и също предупреждение и започват да работят по един и същи проблем. За разрешаването на подобни конфликти обаче е достатъчно да се разработи съгласуван алгоритъм за реагиране на предупреждения - например, ако разделите отговорността за мрежовите устройства между администраторите, тогава няма да има въпроси кой трябва да се справи с конкретен проблем.

Време е да вземете решение

Вече съм решил за себе си кой от трите продукта ще пасне най-добре на моята среда. Избрах системата ManageEngine OpManager с лиценз за 50 устройства по няколко причини.

На първо място, трябва да мога да наблюдавам възможно най-много параметри на моята среда, тъй като това По най-добрия начинизбягвайте неочаквани неуспехи. IN този проблемСистемата OpManager определено е пред конкуренцията. Втората причина е бюджетът. Мога да продължа да използвам нашите стари инструменти за наблюдение при включване/изключване за работни станции и принтери и по този начин да избегна разходите за допълнителни лицензи. И накрая, наистина ми хареса подходът, който ManageEngine възприе при разработването на OpManager, за да се възползва от новите технологии, и мисля, че си струва цената да закупите годишен пакет за поддръжка и поддръжка, за да ви позволи да изтегляте актуализации, докато продуктът се развива.

Нейт Макалмънд ( [имейл защитен]) - ИТ директор в агенция за предоставяне на услуги социални услуги, притежава MCSE, Security и Network+ сертификати, специализира в решения за тънки клиенти и медицински бази данни

Активното мрежово оборудване трябва да осигурява дългосрочна и непрекъсната работа корпоративна мрежа. Навременното идентифициране и отстраняване на неизправностите е ключът към успешната и ефективна работа на компанията. Ето защо е много важно да се обърне специално внимание на система за мониторинг, която да следи състоянието на активното оборудване и да уведомява за отклонения от нормалните показатели системен администраторчрез SMS, електронна поща или други средства за уведомяване.

Система за наблюдениее колекция технически средстваосъществяване на постоянно наблюдение и събиране на информация в местното компютърна мрежавъз основа на анализ на статистически данни, за да се идентифицират дефектни или неправилно работещи агрегати и да се уведомят отговорните лица. Функционалността на съвременните системи за мониторинг ви позволява да наблюдавате състоянието на такива услуги като например:

1) Наличност на хоста

Чрез периодично изпращане на ICMP Echo-Requests до адрес на мрежово устройство

2) Наличност на уеб сървър

Чрез изпращане на HTTP заявка за получаване на страницата

3) Наличие на пощенски услуги

Чрез периодично изпращане на диагностични SMTP съобщения

Освен това можете да измерите времето за реакция на тези услуги.

Периодичните проверки от този вид ви позволяват бързо да определите на какво ниво е възникнал проблемът и незабавно да започнете да го отстранявате.

Фигурата по-горе показва прост пример за внедряване на система за наблюдение, която контролира само четири устройства. В реални условия флотът от активно оборудване може да има много повече възли. За извършване на компетентен мониторинг различни видове възли се комбинират в групи, например група уеб сървъри или група рутери. Този вид разделение помага за систематизиране на статистическата информация и улеснява процеса на наблюдение.

Повечето системи за наблюдение ви позволяват да автоматизирате проверката на устройството чрез SNMP и да извършвате диагностика с помощта на различни добавки (включително тези, създадени ръчно).

Протоколът SNMP (Simple Network Management Protocol) е създаден специално за нуждите на мониторинг на мрежово оборудване. Всички активни L2 и L3 устройства съдържат така наречената MIB (Management Information Base), която съдържа основните параметри на състоянието на оборудването. Например натоварване на процесора, състояние на интерфейса, обем свободно пространствои т.н. Всеки такъв запис съответства на уникален идентификатор OID (Oject IDentifier). Като имате необходимия идентификатор, можете да получите информация за интересуващия ви параметър чрез SNMP протокола. Съвременните системи за наблюдение ви позволяват да автоматизирате този процес. Системата, използвайки SNMP протокола, се свързва с устройството, отправя запитване към него за интересуващия го OID, получава стойността на параметъра и го сравнява с посочения. Ако се установи несъответствие между двете дадени стойности, системата за мониторинг реагира и стартира процеса на предупреждение.

Преди директното внедряване на системата за мониторинг е необходимо да се проведе LAN проучване, резултатът от което трябва да бъде списък на наблюдаваното оборудване, параметри и одобрен алгоритъм за ескалиране на събитията за мониторинг. Въз основа на анализа на мрежовата инфраструктура на клиента се формират първите решения, които определят архитектурата на бъдещата система за мониторинг.

На следващия етап се изготвят спецификации и пакет от проектна документация, като се вземат предвид желанията на клиента.

Последният етап е мащабиране на системата за мониторинг, тоест разширяване на обхвата на наблюдаваната ИТ инфраструктура до това, което се нуждае от клиента.

Внедряването на система за мониторинг е важна стъпка към пълната автоматизация на ИТ инфраструктурата, което води до повишаване на ефективността при нейното използване. Специалистите на нашата компания многократно са разработвали решения, които отговарят на очакванията на клиентите и работят надеждно в продължение на няколко години.

Беше ли полезна за вас тази статия?

Моля те кажи ми защо?

Съжаляваме, че статията не беше полезна за вас: (Моля, ако не е трудно, посочете защо? Ще бъдем много благодарни за подробен отговор. Благодарим ви, че ни помогнахте да станем по-добри!

РЕЗЮМЕ

Този документ е технически проектразработване и внедряване на система за наблюдение на мрежата за обществената мрежа за предаване на данни на град Верхнепишминск на Gerkon LLC. Проектът проведе проучване на съществуващите системи за наблюдение на мрежата, анализира текущата ситуация в предприятието и обоснова избора на конкретни компоненти на системата за наблюдение на мрежата.

Документът съдържа описание на проектните решения и спецификациите на оборудването.

Резултатът от проектирането са разработените решения за внедряване и използване на системата:

§ Пълно описание на всички етапи на проектиране, разработка и внедряване на системата;

§ Ръководство на системния администратор, включително описание на потребителския интерфейс на системата.

Този документ представлява цялостни дизайнерски решения и може да се използва за внедряване на системата.

СПИСЪК НА ЛИСТНИ ГРАФИЧНИ ДОКУМЕНТИ

Таблица 1 - Списък на листове графични документи

1Системи за наблюдение на мрежата220100 4010002Логическа структура на мрежата220100 4010003Алгоритъм на ядрото за наблюдение и предупреждение на мрежата220100 4010004Структура на анализатора на натоварването на мрежовия интерфейс220100 4010005Структура на колектора на системни събития220100 4010006Интерфейс Nagios2 2010 0 4010007 Обобщена структура на системата за наблюдение на мрежата 220100 401000

СПИСЪК НА КОНВЕНЦИИ, СИМВОЛИ И ТЕРМИНИ

Ethernet е стандарт за предаване на данни, издаден от IEEE. Определя как да предавате или получавате данни от обща среда за предаване на данни. Формира долния транспортен слой и се използва от различни протоколи от по-високо ниво. Осигурява скорост на трансфер на данни от 10Mbit/sec.

Fast Ethernet е технология за предаване на данни със скорост 100 Mbit/s, използвайки метода CSMA/CD, като 10Base-T.

FDDI - Fiber Distributed Data Interface - оптичен интерфейс за разпределено предаване на данни - технология за предаване на данни със скорост 100 Mbit/s, използвайки метода token ring.

IEEE - Институт на инженерите по електротехника и електроника (Institute of Electrical and Electronics Engineers) е организация, която разработва и публикува стандарти.

LAN - Local Area Network - локална мрежа, LAN. адрес - Media Access Control - идентификационен номер на мрежово устройство, обикновено определян от производителя.

RFC - Request for Comments - набор от документи, издадени от организацията IEEE, който включва описание на стандарти, спецификации и др.

TCP/IP - Transmission Control Protocol/ Internet Protocol - протокол за контрол на предаването/Интернет протокол.

LAN - Локална мрежа.

OS - Операционна система.

Софтуер - Софтуер.

СКС - Структурна кабелна система.

СУБД - Система за управление на бази данни.

Тенденция - Дългосрочна статистика, която ви позволява да изградите така наречената тенденция.

КОМПЮТЪР - Електронен компютър.

ВЪВЕДЕНИЕ

Информационната инфраструктура на едно модерно предприятие е сложен конгломерат от многомащабни и разнородни мрежи и системи. За да се гарантира безпроблемното им и ефективно функциониране, е необходима платформа за управление в мащаб на предприятието с интегрирани инструменти. Доскоро обаче самата структура на индустрията за управление на мрежата възпрепятстваше създаването на такива системи - „играчите“ на този пазар търсеха лидерство, като пускаха продукти с ограничен обхват, използвайки инструменти и технологии, които не бяха съвместими със системи от други доставчици.

Днес ситуацията се променя към по-добро - появяват се продукти, които претендират да бъдат универсални в управлението на цялото разнообразие от корпоративни информационни ресурси, от настолни системи до мейнфрейми и от локални мрежи до интернет ресурси. В същото време има осъзнаване, че приложенията за управление трябва да бъдат отворени за решения от всички доставчици.

Актуалността на тази работа се дължи на факта, че във връзка с разпространението на персоналните компютри и създаването на автоматизирани работни станции (AWS) на тяхна база се увеличи значението на локалните компютърни мрежи (LAN), чиято диагноза е обект на нашето изследване. Предмет на изследване са основните методи за организиране и провеждане на диагностика на съвременните компютърни мрежи.

"Диагностика на локална мрежа" - процесът на (непрекъснат) анализ на състоянието информационна мрежа. Когато възникне неизправност на мрежовото устройство, фактът на неизправността се записва, определя се нейното местоположение и вид. Изпраща се съобщение за повреда, устройството се изключва и се заменя с резервно.

Мрежовият администратор, който най-често отговаря за извършването на диагностика, трябва да започне да изучава характеристиките на своята мрежа още във фазата на нейното формиране, т. да знаете мрежовата схема и Подробно описаниеконфигурации софтуерпосочване на всички параметри и интерфейси. За обработката и съхраняването на тази информация са подходящи специални системи за мрежова документация. Използвайки ги, системният администратор ще знае предварително всички възможни „скрити дефекти“ и „тесни места“ на своята система, така че в случай на аварийна ситуация да знае какъв е проблемът с хардуера или софтуера, дали програмата е повредени или грешка е довела до действия на оператора.

Мрежовият администратор трябва да помни, че от гледна точка на потребителите качеството на приложния софтуер в мрежата е решаващо. Всички други критерии, като брой грешки при предаване на данни, ниво на натоварване мрежови ресурси, производителността на оборудването и т.н. са второстепенни. „Добра мрежа“ е тази, чиито потребители не забелязват как работи.

Компания

Преддипломният стаж се проведе в компанията Gerkon LLC в отдела за поддръжка като системен администратор. Компанията предлага услуги за достъп до Интернет в градовете Верхняя Пишма и Среднеуралск, използвайки Ethernet технология и комутируеми канали от 1993 г. и е един от първите доставчици на интернет услуги в тези градове. Правилата за предоставяне на услуги се регулират от публичната оферта и правилника.

Научни и производствени задачи на поделението

Отделът за поддръжка решава следния набор от задачи в рамките на дадено предприятие:

§ техническа и технологична организация за осигуряване на достъп до Интернет чрез комутируеми и специализирани канали;

§ техническа и технологична организация на безжичен достъп до Интернет;

§ разпределяне на дисково пространство за съхранение и осигуряване на работата на сайтове (хостинг);

§ работна подкрепа пощенски кутииили виртуален пощенски сървър;

§ разполагане на оборудването на клиента на сайта на доставчика (колокация);

§ Отдаване под наем на специализирани и виртуални сървъри;

§ архивиране на данни;

§ внедряване и поддръжка на корпоративни мрежи на частни предприятия.

1. СИСТЕМИ ЗА МРЕЖОВ МОНИТОРИНГ

Въпреки множеството техники и инструменти за откриване и отстраняване на проблеми в компютърните мрежи, „почвата под краката“ на мрежовите администратори все още е доста разклатена. Компютърните мрежи все повече включват оптични и безжични компоненти, които правят традиционните медни кабелни технологии и инструменти безсмислени. Освен това при скорости над 100 Mbps традиционните диагностични подходи често спират да работят, дори ако предавателната среда е обикновен меден кабел. Въпреки това, може би най-значимата промяна в компютрите мрежови технологииПредизвикателството, пред което администраторите трябваше да се изправят, беше неизбежният преход от Ethernet мрежи със споделена среда към комутирани мрежи, в които отделни сървъри или работни станции често действат като комутирани сегменти.

Вярно е, че с настъпването на технологичните трансформации някои стари проблеми се разрешиха от само себе си. Коаксиален кабел, при който винаги е било по-трудно да се идентифицират електрически повреди, отколкото в случая на усукана двойка, се превръща в рядкост в корпоративни среди. Мрежите Token Ring, чийто основен проблем беше тяхната разлика с Ethernet (а не изобщо техническа слабост), постепенно се заменят от комутирани Ethernet мрежи. Протоколите, които генерират многобройни съобщения за грешка на протокола на мрежовия слой, като SNA, DECnet и AppleTalk, се заменят с IP. Самият стек от IP протоколи стана по-стабилен и по-лесен за поддръжка, както е доказано от милиони клиенти и милиарди уеб страницив интернет. Дори закоравелите противници на Microsoft трябва да признаят, че свързването е ново Windows клиентвръзката с интернет е много по-проста и по-надеждна от инсталирането на използвани преди това TCP/IP стекове на трети страни и отделен софтуер за комутируема връзка.

Колко много модерни технологииВъпреки че затрудняват отстраняването на неизправности и управлението на производителността на мрежата, ситуацията може да бъде още по-лоша, ако ATM технологията стане широко разпространена на ниво компютър. Също така изигра положителна роля, че в края на 90-те години, преди да получат признание, някои други високоскоростни технологии за обмен на данни бяха отхвърлени, включително Token Ring с пропускателна способност от 100 Mbit/s, 100VG-AnyLAN и усъвършенствани мрежи ARCnet. И накрая, много сложният стек от протоколи OSI (който обаче беше легализиран от редица европейски правителства) беше отхвърлен в Съединените щати.

Нека да разгледаме някои текущи проблеми, с които се сблъскват администраторите на фирмени мрежи.

Йерархична топология на компютърни мрежи с магистрални канали Gigabit Ethernetи специални комутационни портове от 10 или дори 100 Mbit/s за индивидуални клиентски системи, направиха възможно увеличаването на максималната пропускателна способност, потенциално достъпна за потребителите, с поне 10-20 пъти. Разбира се, в повечето компютърни мрежи има тесни места на ниво сървър или рутер за достъп, тъй като честотната лента на потребител е значително по-малка от 10 Mbit/s. Поради това замяната на 10 Mbps хъб порт със специален 100 Mbps комутационен порт за крайния възел не винаги води до значително увеличение на скоростта. Въпреки това, ако смятате, че цената на ключовете е напоследъке намалял и повечето предприятия са инсталирали кабел от категория 5, който поддържа Ethernet технология 100 Mbps и инсталирани мрежови карти, които могат да работят със 100 Mbps веднага след рестартиране на системата, става ясно защо е толкова трудно да устоите на изкушението да надстроите. В традиционна споделена медийна LAN анализатор на протоколи или монитор може да изследва целия трафик в даден мрежов сегмент.

Ориз. 1.1 - Традиционна локална мрежа със споделена среда за предаване и анализатор на протоколи

Въпреки че предимството на производителността на комутираната мрежа понякога е едва доловимо, възходът на комутираните архитектури има катастрофални последици за традиционните инструменти за диагностика. В силно сегментирана мрежа анализаторите на протоколи могат да видят само едноадресен трафик на единичен порт на превключвателя, за разлика от наследената мрежова топология, където те биха могли да изследват внимателно всеки пакет в домейна на сблъсък. При такива условия традиционните инструменти за мониторинг не могат да събират статистика за всички „диалози“, тъй като всяка „говореща“ двойка крайни точки използва по същество своя собствена мрежа.

Ориз. 1.2 - Комутирана мрежа

В комутирана мрежа анализаторът на протоколи в един момент може да "види" само един сегмент, освен ако комутаторът не е в състояние да дублира няколко порта едновременно.

За да поддържат контрол над силно сегментираните мрежи, производителите на комутатори предлагат различни инструменти за възстановяване на пълната видимост на мрежата, но много предизвикателства остават по пътя. Превключвателите, които се доставят в момента, обикновено поддържат дублиране на портове, при което трафикът от един порт се дублира към неизползван преди това порт, към който е свързан монитор или анализатор.

„Огледалото“ обаче има редица недостатъци. Първо, само един порт е видим в даден момент, така че отстраняването на проблеми, които засягат множество портове, е трудно. Второ, дублирането може да влоши производителността на комутатора. Трето, повреди обикновено не се възпроизвеждат на огледалния порт физическо ниво, а понякога дори обозначенията на виртуални локални мрежи се губят. И накрая, в много случаи пълнодуплексните Ethernet връзки не могат да бъдат напълно огледални.

Частично решение за анализиране на агрегираните параметри на трафика е използването на възможностите за наблюдение на mini-RMON агентите, особено след като те са вградени във всеки порт на повечето Ethernet комутатори. Въпреки че mini-RMON агентите не поддържат групата Capture обекти на спецификацията RMON II, които предоставят пълнофункционален анализ на протокола, те все още могат да осигурят представа за използването на ресурсите, нивата на грешки и обема на мултикаст.

Някои от недостатъците на технологията за дублиране на портове могат да бъдат преодолени чрез инсталиране на "пасивни кранове", произведени например от Shomiti. Тези устройства са с предварително инсталирани Y-конектори и ви позволяват да наблюдавате действителния сигнал, а не регенерирания, с помощта на анализатор на протоколи или друго устройство.

Следващият наболял проблем е проблемът с характеристиките на оптиката. Администраторите на компютърни мрежи обикновено използват специализирано диагностично оборудване за оптична мрежа само за отстраняване на проблеми с оптичния кабел. Общ стандартен SNMP или базиран на интерфейс софтуер за управление на устройства командна линияможе да идентифицира проблеми на комутатори и рутери с оптични интерфейси. И само няколко мрежови администратори са изправени пред необходимостта да диагностицират SONET устройства.

Що се отнася до оптичните кабели, причините за появата възможни неизправностите съдържат значително по-малко, отколкото в случая на меден кабел. Оптичните сигнали не причиняват пресичане, което се получава, когато сигнал на единия проводник индуцира сигнал на другия - това е най-голямото усложнение. диагностична апаратураза меден кабел. Оптичните кабели са имунизирани срещу електромагнитен шум и индуцирани сигнали, така че не е необходимо да бъдат разположени далеч от асансьорни двигатели и лампи дневна светлина, т.е. всички тези променливи могат да бъдат изключени от диагностичния сценарий.

Силата на сигнала или оптичната мощност в дадена точка наистина е единствената променлива, която трябва да се измерва при отстраняване на проблеми с оптични мрежи. Ако загубата на сигнал може да се определи по целия оптичен канал, тогава почти всеки проблем може да бъде идентифициран. Евтините допълнителни модули за тестери за медни кабели позволяват оптични измервания.

Предприятията, които са разположили голяма оптична инфраструктура и я поддържат сами, може да се наложи да закупят оптичен рефлектометър във времеви домейн (OTDR), който изпълнява същите функции за оптично влакно като рефлектометър във времеви домейн (TDR) за меден кабел. Устройството работи като радар: изпраща импулсни сигнали по кабела и анализира техните отражения, въз основа на които идентифицира повреда в проводника или друга аномалия, след което казва на експерта къде да търси източника на проблема в кабел.

Въпреки че различни доставчици на кабели и конектори са опростили процеса на прекратяване и разклоняване на оптични влакна, той все още изисква известно ниво на специализирани умения и с разумни политики едно предприятие с обширна оптична инфраструктура ще трябва да обучи своите служители. Колкото и добре да е положена кабелната мрежа, винаги има възможност физическо уврежданекабел в резултат на някакъв неочакван инцидент.

Проблеми могат да възникнат и при диагностициране на 802.11b безжични LAN. Самата диагностика е толкова проста, колкото в случая на Ethernet мрежи, базирани на концентратори, тъй като безжичната среда за предаване на информация се споделя между всички собственици на клиентски радиоустройства. Sniffer Technologies първи предложи решение за анализиране на протоколите на такива мрежи с пропускателна способност до 11 Mbps, а впоследствие повечето от водещите производители на анализатори въведоха подобни системи.

За разлика от Ethernet хъб с кабелни връзки, качеството на безжичните клиентски връзки далеч не е стабилно. Микровълновите радиосигнали, използвани във всички локални опции за предаване, са слаби и понякога непредвидими. Дори малки промени в позицията на антената могат сериозно да повлияят на качеството на връзките. Точките за достъп до безжична LAN се доставят с конзола за управление на устройства и това често е по-ефективен диагностичен метод от посещението на безжични клиенти и наблюдението на пропускателна способност и грешки с ръчен анализатор.

Въпреки че проблемите със синхронизирането на данни и инсталирането на устройства, изпитвани от потребителите на персонални цифрови асистенти (PDA), се вписват по-естествено в нуждите на групата техническа поддръжкаотколкото отговорностите на мрежов администратор, не е трудно да се предвиди, че в недалечното бъдеще много такива устройства ще се развият от самостоятелни PC добавки до пълноценни мрежови клиенти.

Като правило, операторите на корпоративни безжични мрежище (или трябва) да възпрепятства внедряването неоправдано отворени системи, при който всеки потребител в зоната на покритие на мрежата и притежаващ съвместима интерфейсна карта получава достъп до всеки информационен кадър на системата. Безжичният протокол за сигурност WEP (Wired Equivalent Privacy) осигурява удостоверяване на потребителя, гаранция за цялост и криптиране на данните, но, както обикновено се случва, сложната система за сигурност усложнява анализа на причините за мрежовите проблеми. В защитени мрежи с активиран WEP диагностичните техници трябва да знаят ключовете или паролите, които защитават информационните ресурси и контролират достъпа до системата. При достъп в режим на получаване на всички пакети, анализаторът на протоколи ще може да види всички заглавки на рамката, но информацията, съдържаща се в тях, ще бъде безсмислена без наличието на ключове.

При диагностициране на тунелирани връзки, които много производители наричат ​​виртуални частни мрежи отдалечен достъп, възникналите проблеми са подобни на тези, възникнали при анализиране на безжични мрежи с криптиране. Ако трафикът не преминава през тунелирания канал, причината за проблема не е лесна за определяне. Това може да е грешка при удостоверяване, повреда в една от крайните точки или задръстване в публичната интернет зона. Опитът да се използва анализатор на протоколи за идентифициране на грешки на високо ниво в тунелиран трафик би бил загуба на усилия, тъй като съдържанието на данните, както и заглавките на приложението, транспорта и мрежовия слой са криптирани. Като цяло мерките, предприети за подобряване на сигурността на корпоративните мрежи, обикновено затрудняват идентифицирането на грешки и проблеми с производителността. Защитните стени, прокси сървърите и системите за откриване на проникване могат допълнително да усложнят отстраняването на проблеми.

Следователно проблемът с диагностицирането на компютърни мрежи е актуален и в крайна сметка диагностицирането на неизправности е задача на управлението. За най-критичните корпоративни системи, продължителната реставрация не е приемлива, така че единственото решение е да се използва резервни устройстваи процеси, които могат да поемат необходимите функции веднага след възникване на повреди. В някои предприятия мрежите винаги имат допълнителен резервен компонент в случай, че основният компонент се повреди, т.е. n x 2 компонента, където n е броят на основните компоненти, необходими за осигуряване на приемлива производителност. Ако средното време за ремонт (MTTR) е достатъчно високо, тогава може да е необходимо дори повече резервиране. Факт е, че времето за ремонт не е лесно да се предвиди и значителните разходи по време на непредсказуем период на възстановяване са знак за лошо управление.

За по-малко критични системи резервирането може да не е икономически осъществимо, в който случай може да си струва да инвестирате в най-ефективните инструменти (и обучение на персонала), за да ускорите отстраняването на неизправности във вашето предприятие. В допълнение, поддръжката за определени системи може да бъде възложена на външни изпълнители или чрез сключване на договор за тях вътрешно, чрез използване на външни центрове за данни или чрез използване на доставчици на услуги за приложения (ASP) или доставчици на услуги за управление. В допълнение към разходите, най-важният фактор, който влияе върху решението за използване на услуги на трети страни, е нивото на компетентност на вътрешния персонал. Мрежовите администратори трябва да решат дали определена функция е толкова тясно свързана със специфичните цели на предприятието, че не може да се очаква външен специалист да свърши по-добра работа, отколкото може да бъде свършена от собствените служители на компанията.

Почти веднага след разгръщането на първите корпоративни мрежи, чиято надеждност остави много да се желае, производителите и разработчиците представиха концепцията за „самовъзстановяващи се мрежи“. Съвременните мрежи със сигурност са по-надеждни, отколкото през 90-те години, но не защото проблемите са се самокоригирали. Отстраняване на софтуерни и хардуерни повреди модерни мреживсе още изискват човешка намеса и не се очакват фундаментални промени в това състояние на нещата в близко бъдеще. Техниките и инструментите за диагностика са в рамките на настоящата практика и технология, но все още не са достигнали ниво, което може значително да спести време на мрежовите администратори, докато се борят с мрежови проблеми и затруднения в производителността.

1.1 Диагностичен софтуер

Сред софтуерните инструменти за диагностика на компютърни мрежи можем да подчертаем специални системи за управление на мрежата (системи за управление на мрежата) - централизирани софтуерни системи, които събират данни за състоянието на мрежовите възли и комуникационните устройства, както и данни за трафика, циркулиращ в мрежата. Тези системи не само наблюдават и анализират мрежата, но и извършват действия по управление на мрежата в автоматичен или полуавтоматичен режим – активиране и дезактивиране на портове на устройства, промяна на параметрите на моста, адресни таблици на мостове, комутатори и рутери и др. Примери за системи за управление включват популярните системи HPOpenView, SunNetManager, IBMNetView.

Инструментите за управление на системата изпълняват функции, подобни на тези на системите за управление, но във връзка с комуникационно оборудване. В същото време някои функции на тези два типа системи за управление могат да бъдат дублирани; например инструментите за управление на системата могат да извършват прост анализ на мрежовия трафик.

Експертни системи. Този тип система акумулира човешки знания за идентифициране на причините за ненормална работа на мрежите и възможните начини за привеждане на мрежата в работно състояние. Експертните системи често се реализират като отделни подсистеми на различни инструменти за наблюдение и анализ на мрежата: системи за управление на мрежата, анализатори на протоколи, мрежови анализатори. Най-простата версия на експертна система е контекстно-чувствителна помощна система. По-сложните експертни системи са така наречените бази от знания, които имат елементи на изкуствен интелект. Пример за такава система е експертната система, вградена в системата за управление Spectrum на Cabletron.

1.1.1 Анализатори на протоколи

Когато се проектира нова или надгражда стара мрежа, често има нужда от количествено измерване на определени мрежови характеристики, като например интензивността на потоците от данни по мрежовите комуникационни линии, закъсненията, които възникват на различни етапи от обработката на пакети, времето за отговор на заявки на един тип или друг, честотата на възникване на определени събития и други характеристики.

За тези цели могат да се използват различни инструменти и преди всичко инструменти за наблюдение в системите за управление на мрежата, които вече бяха обсъдени по-рано. Някои мрежови измервания могат да се извършват и със софтуерни измервателни уреди, вградени в операционната система; пример за това е компонентът Windows Performance Monitor OS. Дори съвременните кабелни тестери са способни да улавят пакети и да анализират тяхното съдържание.

Но най-модерният инструмент за изследване на мрежата е анализатор на протоколи. Процесът на анализ на протокола включва улавяне на пакети, циркулиращи в мрежа, които прилагат конкретен мрежов протокол, и изучаване на съдържанието на тези пакети. Въз основа на резултатите от анализа е възможно да се направят разумни и балансирани промени във всеки мрежов компонент, да се оптимизира неговата производителност и да се отстранят проблеми. Очевидно, за да се направят каквито и да било заключения относно въздействието на промяната върху мрежата, е необходимо да се анализират протоколите както преди, така и след извършването на промяната.

Анализаторът на протоколи е независимо специализирано устройство или персонален компютър, обикновено преносим, ​​от клас Htebook, оборудван със специална мрежова карта и подходящ софтуер. Използваната мрежова карта и софтуер трябва да отговарят на мрежовата топология (пръстен, шина, звезда). Анализаторът се свързва към мрежата по същия начин като обикновен възел. Разликата е, че анализаторът може да получи всички пакети данни, предадени по мрежата, докато обикновената станция може да получи само тези, адресирани до нея. Софтуерът на анализатора се състои от ядро, което поддържа работата на мрежовия адаптер и декодира получените данни, и допълнителен програмен код, в зависимост от вида на топологията на изследваната мрежа. Освен това се доставят редица специфични за протокола процедури за декодиране, като IPX. Някои анализатори могат също да включват експертна система, която може да предостави на потребителя препоръки за това какви експерименти трябва да се извършат в дадена ситуация, какво могат да означават определени резултати от измерване и как да се елиминират определени видове мрежови повреди.

Въпреки относителното разнообразие от анализатори на протоколи на пазара, има някои характеристики, които са общи за всички тях в една или друга степен:

Потребителски интерфейс. Повечето анализатори имат разработен удобен за потребителя интерфейс, обикновено базиран на Windows или Motif. Този интерфейс позволява на потребителя да: показва резултатите от анализа на интензивността на трафика; получавате моментална и средна статистическа оценка на производителността на мрежата; задайте определени събития и критични ситуации, за да проследите тяхното възникване; декодиране на протоколи от различни нива и представяне на съдържанието на пакетите в разбираема форма.

Буфер за улавяне. Буферите на различните анализатори се различават по размер. Буферът може да се намира на инсталирана мрежова карта или за него може да бъде отделено място в RAM на някой от компютрите в мрежата. Ако буферът се намира на мрежовата карта, тогава той се управлява хардуерно и поради това скоростта на въвеждане се увеличава. Това обаче оскъпява анализатора. Ако изпълнението на процедурата за улавяне е недостатъчно, част от информацията ще бъде загубена и анализът ще бъде невъзможен. Размерът на буфера определя възможностите за анализ на повече или по-малко представителни проби от уловените данни. Но колкото и голям да е буферът за улавяне, рано или късно той ще се напълни. В този случай или прихващането спира, или пълненето започва от началото на буфера.

Филтри. Филтрите ви позволяват да контролирате процеса на събиране на данни и по този начин спестявате буферно пространство. В зависимост от стойността на определени пакетни полета, зададени като условие за филтър, пакетът или се игнорира, или се записва в буфера за улавяне. Използването на филтри значително ускорява и опростява анализа, тъй като елиминира преглеждането на ненужни в момента пакети.

Превключвателите са определени условия, определени от оператора за стартиране и спиране на процеса на прихващане на данни от мрежата. Такива условия могат да включват изпълнение на ръчни команди за стартиране и спиране на процеса на улавяне, час от деня, продължителност на процеса на улавяне и появата на определени стойности в кадри с данни. Превключвателите могат да се използват заедно с филтри, което позволява по-подробен и нюансиран анализ, както и по-продуктивно използване на ограниченото буферно пространство за улавяне.

Търсене. Някои анализатори на протоколи ви позволяват да автоматизирате преглеждането на информация в буфера и да намирате данни в него въз основа на определени критерии. Докато филтрите проверяват входния поток, за да видят дали отговаря на условията на филтъра, функциите за търсене се прилагат към данните, които вече са натрупани в буфера.

Методологията на анализа може да бъде представена в следните шест етапа:

Улавяне на данни.

Преглед на заснетите данни.

Анализ на данни.

Откриване на грешки. (Повечето анализатори улесняват тази работа, като откриват типове грешки и идентифицират станцията, от която идва пакетът за грешка.)

Изследване на ефективността. Изчислява се степента на използване на честотната лента на мрежата или средното време за отговор на заявка.

Детайлно проучване на отделни участъци от мрежата. Съдържанието на този етап се уточнява с напредването на анализа.

Обикновено процесът на анализиране на протоколите отнема сравнително малко време - 1-2 работни дни.

Повечето съвременни анализатори ви позволяват да анализирате няколко глобални мрежови протокола наведнъж, като X.25, PPP, SLIP, SDLC/SNA, frame relay, SMDS, ISDN, протоколи за мост/рутер (3Com, Cisco, Bay Networks и други). Такива анализатори ви позволяват да измервате различни параметрипротоколи, анализ на трафика в мрежата, преобразуване между локални и глобални мрежови протоколи, забавяне на рутери по време на тези преобразувания и т.н. По-усъвършенстваните устройства предоставят възможност за симулиране и декодиране на глобални мрежови протоколи, „стрес“ тестване, измерване на максимална пропускателна способност, тестване на качеството предоставени услуги. В името на гъвкавостта почти всички WAN анализатори на протоколи прилагат функции за тестване за LAN и всички основни интерфейси. Някои устройства могат да анализират телефонни протоколи. И най-модерните модели могат да декодират и представят в удобен вариантвсичките седем OSI нива. Появата на ATM накара производителите да оборудват своите анализатори с инструменти за тестване на тези мрежи. Такива устройства могат да провеждат пълно тестване на E-1/E-3 ATM мрежи с поддръжка за мониторинг и симулация. Наборът от сервизни функции на анализатора е много важен. Някои от тях, като възможността за дистанционно управление на устройството, са просто незаменими.

По този начин съвременните WAN/LAN/DTM анализатори на протоколи могат да откриват грешки в конфигурацията на рутери и мостове; задайте вида на трафика, изпратен през глобалната мрежа; определяне на използвания скоростен диапазон, оптимизиране на съотношението между пропускателна способност и брой канали; локализиране на източника на неправилен трафик; Извършване на тестване на сериен интерфейс и пълно тестване на ATM; извършва пълен мониторинг и декодиране на основните протоколи на всеки канал; анализира статистика в реално време, включително анализ на трафика на локалната мрежа през глобалните мрежи.

1.1.2 Протоколи за наблюдение

Протоколът SNMP (Simple Network Management Protocol) е протокол за управление на комуникационна мрежа, базиран на TCP/IP архитектурата.

Въз основа на концепцията TMN през 1980-1990 г. Различни органи за стандартизация са разработили редица протоколи за управление на мрежи за данни с различен обхват на изпълнение на функциите на TMN. Един тип такъв протокол за управление е SNMP. Протоколът SNMP е разработен за тестване на функционирането на мрежови рутери и мостове. Впоследствие обхватът на протокола обхвана други мрежови устройства, като хъбове, шлюзове, терминални сървъри, LAN Manager сървъри, компютри Windows контрол NT и др. В допълнение, протоколът позволява възможността за извършване на промени във функционирането на тези устройства.

Тази технология е предназначена да осигури управление и контрол върху устройства и приложения в комуникационна мрежа чрез обмен на контролна информация между агенти, разположени на мрежови устройства, и мениджъри, разположени на контролни станции. SNMP дефинира мрежа като колекция от станции за управление на мрежата и мрежови елементи (хостове, шлюзове и рутери, терминални сървъри), които заедно осигуряват административни комуникации между станции за управление на мрежата и мрежови агенти.

При използване на SNMP има управлявани и контролни системи. Управляваната система включва компонент, наречен агент, който изпраща отчети до управляващата система. По същество SNMP агентите предават информация за управление на системите за управление като променливи (като „свободна памет“, „име на системата“, „брой изпълнявани процеси“).

Агентът в протокола SNMP е обработващ елемент, който предоставя на мениджърите, разположени в мрежови контролни станции, достъп до стойностите на MIB променливите и по този начин им позволява да изпълняват функции за управление и наблюдение на устройството.

Софтуерният агент е резидентна програма, която изпълнява функции за управление и също така събира статистически данни за прехвърлянето им в информационната база на мрежово устройство.

Хардуерен агент е вграден хардуер (с процесор и памет), в който се съхраняват софтуерни агенти.

Променливите, достъпни чрез SNMP, са организирани в йерархия. Тези йерархии и други метаданни (като тип променлива и описание) се описват от информационни бази за управление (MIB).

Днес има няколко стандарта за бази данни с управленска информация. Основните са стандартите MIB-I и MIB-II, както и версията на базата данни за дистанционно управление RMON MIB. Освен това има стандарти за MIB за специфични устройства от конкретен тип (например MIB за хъбове или MIB за модеми), както и собствени MIB за специфични производители на оборудване.

Оригиналната MIB-I спецификация дефинира само операции за четене на стойности на променливи. Операциите за промяна или задаване на стойности на обекти са част от спецификациите на MIB-II.

Версия MIB-I (RFC 1156) дефинира до 114 обекта, които са разделени на 8 групи:

Система - общи данни за устройството (например ID на доставчика, време на последна инициализация на системата).

Интерфейси - описва параметрите на мрежовите интерфейси на устройството (например техния брой, видове, обменни курсове, максимален размер на пакета).

AddressTranslationTable - описва съответствието между мрежови и физически адреси (например чрез ARP протокола).

InternetProtocol - данни, свързани с IP протокола (адреси на IP шлюзове, хостове, статистика за IP пакети).

ICMP - данни, свързани с протокола за обмен на контролни съобщения ICMP.

TCP - данни, свързани с TCP протокола (например за TCP връзки).

UDP - данни, свързани с UDP протокола (брой предадени, получени и грешни UPD дейтаграми).

EGP - данни, свързани с протокола за обмен на информация за маршрутизиране ExteriorGatewayProtocol, използван в Интернет (броят съобщения, получени с грешки и без грешки).

От този списък с групи променливи става ясно, че стандартът MIB-I е разработен със строг фокус върху управлението на рутери, които поддържат TCP/IP стекови протоколи.

Във версия MIB-II (RFC 1213), приета през 1992 г., наборът от стандартни обекти беше значително разширен (до 185), а броят на групите се увеличи до 10.

RMON агенти

Най-новото допълнение към функционалност SNMP е спецификация на RMON, която позволява дистанционно взаимодействие с MIB.

Стандартът RMON датира от ноември 1991 г., когато Internet Engineering Task Force пусна RFC 1271, „Информационна база за управление на отдалечено наблюдение на мрежата“. Този документсъдържаше описание на RMON за Ethernet мрежи - протокол за мониторинг на компютърна мрежа, разширение на SNMP, който, подобно на SNMP, се основава на събирането и анализа на информация за естеството на информацията, предавана по мрежата. Както и при SNMP, информацията се събира от хардуерни и софтуерни агенти, данните от които се изпращат до компютъра, където е инсталирано приложението за управление на мрежата. Разликата между RMON и неговия предшественик се състои преди всичко в естеството на събраната информация - ако в SNMP тази информация характеризира само събития, случващи се на устройството, където е инсталиран агентът, тогава RMON изисква получените данни да характеризират трафика между мрежови устройства.

Преди RMON SNMP не можеше да се използва дистанционно; позволяваше само локално управление на устройства. RMON MIB има подобрен набор от свойства за дистанционно управление, тъй като съдържа обобщена информация за устройството, която не изисква предаване по мрежата големи обемиинформация. Обектите RMON MIB включват допълнителни броячи на грешки в пакети, по-гъвкави графични тенденции и статистически анализ, по-мощни инструменти за филтриране за улавяне и анализиране на отделни пакети и по-сложни условия за предупреждение. RMON MIB агентите са по-интелигентни от MIB-I или MIB-II агентите и изпълняват голяма част от работата по обработка на информацията за устройството, която преди се извършваше от мениджърите. Тези агенти могат да бъдат разположени в различни комуникационни устройства и могат също така да бъдат внедрени като отделни софтуерни модули, работещи на универсални компютри и лаптопи (LANalyzerHvell е пример).

Интелигентността на агентите RMON им позволява да извършват прости действия за диагностициране на повреди и предупреждават за възможни повреди - например в рамките на технологията RMON е възможно да се събират данни за нормално функциониранемрежа (т.е. извършете така наречената базова линия) и след това задайте предупредителни сигнали, когато режимът на работа на мрежата се отклони от базовата линия - това може да означава, по-специално, че оборудването не работи напълно. Чрез комбиниране на информация, получена от RMON агенти, приложението за управление може да помогне на мрежов администратор (намиращ се например на хиляди километри от мрежовия сегмент, който се анализира) да локализира проблема и да разработи оптимален план за действие за разрешаването му.

Информацията за RMON се събира от хардуерни и софтуерни сонди, свързани директно към мрежата. За да изпълни задачата за събиране и първичен анализ на данни, сондата трябва да има достатъчно изчислителни ресурси и RAM. В момента на пазара има три вида сонди: интегрирани, компютърно базирани и самостоятелни. Един продукт се счита за съвместим с RMON, ако прилага поне една група RMON. Разбира се, колкото повече RMON групи данни са внедрени в даден продукт, толкова по-скъп е, от една страна, и от друга, толкова по-пълна информация за работата на мрежата предоставя.

Вградените сонди са разширителни модули за мрежови устройства. Такива модули се произвеждат от много производители, по-специално от такива големи компании като 3Com, Cabletron, Bay Networks и Cisco. (Между другото, 3Com и Bay Networks наскоро придобиха Axon и ARMON, признати лидери в разработването и производството на инструменти за управление на RMON. Такъв интерес към тази технология от страна на големите производители на мрежово оборудване още веднъж показва колко необходимо е дистанционното наблюдение за потребителите.) Решението за интегриране на RMON модули в хъбове изглежда естествено, защото от наблюдението на тези устройства може да се добие представа за работата на сегмента. Предимството на такива сонди е очевидно: те ви позволяват да получите информация за всички основни групи RMON данни на сравнително ниска цена. Недостатъкът, на първо място, е, че производителността не е много висока, което се проявява по-специално във факта, че вградените сонди често не поддържат всички групи данни RMON. Неотдавна 3Com обяви намерението си да пусне поддържащи RMON драйвери за мрежови адаптери Etherlink III и Fast Ethernet. В резултат на това ще бъде възможно да се събират и анализират RMON данни директно от работни станции в мрежата.

Компютърно базираните сонди са просто компютри, свързани към мрежа с софтуерен агент RMON. Тези сонди (като Cornerstone Agent 2.5 на Network General) имат по-висока производителност от вградените сонди и обикновено поддържат всички RMON групи данни. Те са по-скъпи от вградените сонди, но много по-евтини от самостоятелните сонди. В допълнение, компютърно базираните сонди имат доста голям размер, което понякога може да ограничи възможностите за тяхното приложение.

Автономните сонди имат най-висока производителност; Както е лесно да се разбере, това са в същото време най-скъпите продукти от всички описани. Обикновено самостоятелната сонда е процесор (клас i486 или RISC процесор), оборудван с достатъчно RAM и мрежов адаптер. Лидерите в този пазарен сектор са Frontier и Hewlett-Packard. Сондите от този тип са малки по размер и много мобилни - много лесно се свързват и изключват от мрежата. При решаването на проблема с управлението на мрежа от глобален мащаб това, разбира се, не е много важно свойство, но ако инструментите RMON се използват за анализ на работата на средно голяма корпоративна мрежа, тогава (предвид високата цена на устройствата ) мобилността на сондите може да играе много положителна роля.

Обектът RMON е номериран 16 в набора от обекти MIB, а самият обект RMON, както е дефиниран в RFC 1271, се състои от десет групи данни.

Статистика - текущи натрупани статистически данни за характеристиките на пакетите, брой колизии и др.

История - статистически данни, записвани на определени интервали за последващ анализ на тенденциите в техните промени.

Аларми - прагови стойности на статистически показатели, при превишаване на които агентът RMON изпраща съобщение до мениджъра. Позволява на потребителя да дефинира диапазон от прагови нива (тези прагове може да са сред най-много различни неща- всеки параметър от групата статистики, амплитудата или скоростта на промяната му и много други), при превишаване на които се генерира аларма. Потребителят може също да определи при какви условия превишаването на праговата стойност трябва да бъде придружено от алармен сигнал - това ще избегне генерирането на сигнал „за нищо“, което е лошо, първо, защото никой не обръща внимание на постоянно горяща червена светлина и второ , защото прехвърлянето на ненужно алармипо мрежата води до прекомерно натоварване на комуникационните линии. Алармата обикновено се изпраща до група събития, където се определя какво да се прави с нея по-нататък.

Хост - информация за мрежовите хостове, включително техните MAC адреси.

HostTopN - таблица с най-натоварените хостове в мрежата. Таблицата Top N (HostTopN) съдържа списък с първите N хостове, характеризиращи се с максимална стойностдаден статистически параметър за даден интервал. Например, можете да поискате списък с 10 хоста, които са имали най-много грешки през последните 24 часа. Този списък ще бъде съставен от самия агент, а приложението за управление ще получи само адресите на тези хостове и стойностите на съответните статистически параметри. Ясно е до каква степен този подход пести мрежови ресурси

TrafficMatrix - статистика за интензивността на трафика между всяка двойка мрежови хостове, организирана под формата на матрица. Редовете на тази матрица са номерирани в съответствие с MAC адресите на станциите източник на съобщението, а колоните са номерирани в съответствие с адресите на станциите получатели. Матричните елементи характеризират интензивността на трафика между съответните станции и броя на грешките. Анализирайки такава матрица, потребителят може лесно да разбере кои двойки станции генерират най-интензивен трафик. Тази матрица отново се формира от самия агент, така че не е необходимо да се прехвърлят големи количества данни към централен компютъротговарящ за управлението на мрежата.

Филтър - условия за филтриране на пакети. Критериите, по които се филтрират пакетите, могат да бъдат много разнообразни - например можете да изисквате всички пакети, чиято дължина е по-малка от определена зададена стойност, да бъдат филтрирани като грешни. Можем да кажем, че инсталирането на филтър съответства на организирането на канал за предаване на пакет. Накъде води този канал се определя от потребителя. Например, всички грешни пакети могат да бъдат прихванати и изпратени до подходящия буфер. В допълнение, появата на пакет, който отговаря на инсталирания филтър, може да се счита за събитие, на което системата трябва да реагира по предварително определен начин.

PacketCapture - условия за прихващане на пакети. Групата за улавяне на пакети съдържа буфери за улавяне, към които се изпращат пакети, чиито атрибути отговарят на условията, посочени във филтърната група. В този случай не може да бъде уловен целият пакет, а да речем само първите няколко десетки байта от пакета. Съдържанието на буферите за улавяне може впоследствие да бъде анализирано с помощта на различни софтуерни инструменти, разкривайки редица много полезни характеристики на мрежата. Чрез възстановяване на филтрите за определени характеристики е възможно да се характеризират различни параметри на работата на мрежата.

Събитие - условия за регистриране и генериране на събития. Групата събития определя кога трябва да бъде изпратена аларма към приложението за управление, кога да се прихванат пакети и като цяло как да се реагира на определени събития, възникващи в мрежата, например, когато праговите стойности, ​​посочени в групата аларми, са превишено: дали да зададете уведомяване на контролното приложение или просто трябва да влезете това събитиеи продължавайте да работите. Събитията може да не са свързани със задействане на аларми - например изпращането на пакет към буфера за улавяне също е събитие.

Тези групи са номерирани по ред, така че например групата Hosts има числово име 1.3.6.1.2.1.16.4.

Десетата група се състои от специални обекти на протокола TokenRing.

Общо стандартът RMON MIB дефинира около 200 обекта в 10 групи, документирани в два документа - RFC 1271 за Ethernet мрежи и RFC 1513 за TokenRing мрежи.

Отличителна черта на стандарта RMON MIB е неговата независимост от протокола на мрежовия слой (за разлика от стандартите MIB-I и MIB-II, които са фокусирани върху TCP/IP протоколи). Поради това е удобно да се използва в хетерогенни среди, използвайки различни протоколи на мрежовия слой.

1.2 Популярни системи за управление на мрежата

Система за управление на мрежата - хардуер и/или софтуер за наблюдение и управление на мрежови възли. Софтуерът на системата за управление на мрежата се състои от агенти, които се намират на мрежови устройства и предават информация към платформата за управление на мрежата. Метод обмен на информациямежду контролните приложения и агентите на устройствата се определя от протоколи.

Системите за управление на мрежата трябва да притежават редица качества:

истинско разпространение в съответствие с концепцията клиент/сървър,

мащабируемост,

откритост за справяне с разнородни - от настолни компютрикъм мейнфрейми - оборудване.

Първите две свойства са тясно свързани. Добра мащабируемост се постига благодарение на разпределението на системата за управление. Разпределението означава, че системата може да включва няколко сървъра и клиенти. Сървърите (от мениджъри) събират данни за текущото състояние на мрежата от агенти (SNMP, CMIP или RMON), вградени в мрежовото оборудване и ги натрупват в своята база данни. Клиентите са графични конзоли, управлявани от мрежови администратори. Клиентският софтуер на системата за управление получава заявки за извършване на всякакви действия от администратора (например изграждане на подробна карта на част от мрежата) и се свързва със сървъра за необходимата информация. Ако сървърът има необходимата информация, той незабавно я предава на клиента; ако не, тогава се опитва да я събере от агентите.

Ранните версии на системите за управление комбинираха всички функции в един компютър, който се управляваше от администратор. За малки мрежи или мрежи с малко управлявано оборудване тази структура се оказва доста задоволителна, но с голямо количество управлявано оборудване единственият компютър, към който тече информация от всички мрежови устройства, се превръща в пречка. И мрежата не може да се справи с големия поток от данни, а самият компютър няма време да ги обработи. В допълнение, голяма мрежа обикновено се управлява от повече от един администратор, следователно, в допълнение към няколко сървъра, една голяма мрежа трябва да има няколко конзоли, на които работят мрежовите администратори, и всяка конзола трябва да предоставя специфична информация, която отговаря на текущите нужди на конкретен администратор.

Поддръжката на хетерогенно оборудване е по-скоро желана, отколкото действителна характеристика на днешните системи за управление. Четири от най-популярните продукти за мрежово управление включват Spectrum на Cabletron Systems, OpenView на Hewlett-Packard, NetView на IBM и Solstice на SunSoft, подразделение на SunMicrosystems. Три от четири компании произвеждат сами комуникационно оборудване. Естествено, Spectrum работи най-добре с оборудване на Cabletron, OpenView с оборудване на Hewlett-Packard и NetView с оборудване на IBM.

При изграждане на мрежова карта, която се състои от оборудване от други производители, тези системи започват да правят грешки и да бъркат едни устройства с други, а когато управляват тези устройства, те поддържат само основните им функции и много полезни допълнителни функции, които отличават това устройствоот останалите системата за управление просто не разбира и следователно не може да ги използва.

За да коригират този недостатък, разработчиците на системи за управление включват поддръжка не само за стандартни MIB I, MIB II и RMON MIB, но и за много собствени MIB от производителите. Лидер в тази област е системата Spectrum, която поддържа около 1000 MIB от различни производители.

Друг начин за по-добра поддръжка на конкретно оборудване е да се използва приложение, базирано на някаква платформа за управление от компанията, която произвежда това оборудване. Водещи компании - производители на комуникационно оборудване - са разработили и доставят изключително сложни и многофункционални системи за управление на своето оборудване. Най-известните системи от този клас включват Optivity от BayNetworks, CiscoWorks от CiscoSystems и Transcend от 3Com. Optivity, например, ви позволява да наблюдавате и управлявате мрежи, състоящи се от BayNetwork рутери, комутатори и хъбове, като се възползвате напълно от всичките им възможности и свойства. Оборудване от други производители се поддържа на ниво основни контролни функции. Optivity работи на платформите OpenView на Hewlett-Packard и SunNetManager на SunSoft (предшественик на Solstice). Изпълнението на мултисистемна платформа за управление като Optivity обаче е твърде сложно и изисква компютрите, които я изпълняват, да бъдат много способни. мощни процесории голяма RAM памет.

Въпреки това, ако мрежата е доминирана от оборудване от един производител, тогава наличието на приложения за управление от този производител за всяка популярна платформа за управление позволява на мрежовите администратори успешно да решават много проблеми. Следователно разработчиците на платформи за управление предоставят инструменти, които улесняват разработката на приложения, а наличието и количеството на такива приложения се считат за много важен фактор при избора на платформа за управление.

Отвореността на платформата за управление зависи и от формата на съхранение на събраните данни за състоянието на мрежата. Повечето водещи платформи ви позволяват да съхранявате данни в търговски бази данни като Oracle, Ingres или Informix. Използването на универсална СУБД намалява скоростта на системата за управление в сравнение със съхраняването на данни във файлове операционна система, но ви позволява да обработвате тези данни от всякакви приложения, които могат да работят с тези СУБД.

2. ФОРМУЛИРАНЕ НА ПРОБЛЕМА

В съответствие с настоящата ситуация беше решено да се разработи и внедри система за наблюдение на мрежата, която да реши всички горепосочени проблеми.

2.1 Техническо задание

Разработете и внедрите система за мониторинг, която ви позволява да наблюдавате както комутатори, рутери от различни производители, така и сървъри на различни платформи. Съсредоточете се върху употребата отворени протоколии системи, с максимално използване на готови разработки от фонда за безплатен софтуер.

2.2 Актуализирани технически спецификации

В хода на по-нататъшното формулиране на проблема и изследването на предметната област, като се вземат предвид икономическите и времевите инвестиции, бяха изяснени техническите спецификации:

Системата трябва да отговаря на следните изисквания:

§ минимални изисквания за хардуерни ресурси;

§ отворен код за всички компоненти на комплекса;

§ разширяемост и скалируемост на системата;

§ стандартни средствапредоставяне на диагностична информация;

§ наличие на подробна документация за всички използвани софтуерни продукти;

§ умение за работа с оборудване от различни производители.

3. ПРЕДЛАГАНА СИСТЕМА

1 Избор на система за наблюдение на мрежата

В съответствие с актуализираните технически спецификации, системата Nagios е най-подходяща като ядро ​​на система за наблюдение на мрежата, тъй като има следните качества:

§ има инструменти за генериране на диаграми;

§ има инструменти за генериране на отчети;

§ има възможност за логическо групиране;

§ има вградена система за регистриране на тенденциите и тяхното прогнозиране;

§ възможно е автоматично добавяне на нови устройства (Autodiscovery) с помощта на официалния плъгин;

§ има възможност за разширен мониторинг на хоста с помощта на агент;

§ Поддръжка на SNMP протокол чрез плъгин;

§ Поддръжка на Syslog протокол чрез плъгин;

§ поддръжка на външни скриптове;

§ поддръжка на персонализирани добавки и възможност за бързо и лесно създаване на такива;

§ вградени тригери и събития;

§ пълнофункционален уеб интерфейс;

§ възможност за разпределено наблюдение;

§ инвентаризация чрез плъгин;

§ възможност за съхраняване на данни както във файлове, така и в бази данни SQL данни, което е много важно при увеличаване на обемите;

§ GPL лиценз и следователно безплатна основна доставка, поддръжка и кодове с отворен код на системното ядро ​​и съпътстващите компоненти;

§ динамични и адаптивни карти;

§ контрол на достъпа;

§ вграден език за описание на хостове, услуги и проверки;

§ възможност за проследяване на потребителите.

Системата за наблюдение на мрежата Zabbix има подобен набор от параметри, но по време на внедряването имаше много по-малко функционалност от Nagios и имаше статус на бета версия. В допълнение, проучване на тематични форуми и емисии с новини показа, че Nagios е най-разпространеният сред потребителите, което означава наличието на документация, написана от потребителите, и трудните аспекти на конфигурацията, описани възможно най-подробно.

Nagios ви позволява да наблюдавате мрежови услуги като SMTP, TELNET, SSH, HTTP, DNS, POP3, IMAP, NNTP и много други. Освен това можете да наблюдавате използването на сървърните ресурси, като потребление на дисково пространство, свободна памет и натоварване на процесора. Възможно е да създадете свои собствени манипулатори на събития. Тези манипулатори ще бъдат изпълнени, когато възникнат определени събития, предизвикани от проверки на услуги или сървъри. Този подход ще ви позволи активно да реагирате на текущите събития и да се опитате автоматично да разрешите проблемите, които възникват. Например, можете да създадете манипулатор на събития, който независимо ще рестартира прекъсната услуга. Друго предимство на системата за наблюдение Nagios е възможността за дистанционно управление чрез wap интерфейса на мобилен телефон. Използвайки концепцията за "родителски" хостове, е лесно да се опише йерархията и зависимостите между всички хостове. Този подход е изключително полезен за големи мрежи, защото позволява сложна диагностика. И това качество от своя страна помага да се разграничат неработещите хостове от тези, които в момента не са достъпни поради проблеми в работата на междинните връзки. Nagios може да изгражда графики на наблюдаваните системи и карти на наблюдаваната мрежова инфраструктура.

От своя опит в работата с Nagios, авторът може да даде пример, показващ колко полезен се е оказал той в личната му практика. Във външния мрежов интерфейс на защитната стена загубата на пакети започна на всеки няколко часа. Поради неизправността бяха загубени до 20 процента от преминаващия трафик. След като измина една минута, другият интерфейс отново започна да работи според очакванията. Поради плаващия характер на този проблем, в продължение на няколко седмици не беше възможно да се разбере защо периодично възникват краткотрайни прекъсвания при работа с интернет. Без Nagios отстраняването на неизправности ще отнеме много време.

Много администратори са запознати с предшественика на Nagios, наречен NetSaint. Въпреки факта, че сайтът на проекта NetSaint все още функционира правилно, новите разработки се основават на изходния код на Nagios. Затова се препоръчва на всички бавно да се преместят в Нагиос.

Документацията, която идва с Nagios, посочва, че той ще работи надеждно и на много други Unix системи. подобни системи. За да покажем уеб интерфейса на Nagios, от който се нуждаем Apache сървър. Вие сте свободни да използвате всеки друг, но в тази работа Apache ще се разглежда като най-често срещаният уеб сървър на Unix платформи. Можете да инсталирате система за наблюдение изобщо без уеб интерфейс, но ние няма да направим това, защото това значително намалява лекотата на използване.

4. РАЗРАБОТКА НА СОФТУЕР

Като хардуер на внедрената система може да се използва обикновен IBM-съвместим компютър, но като се вземе предвид възможността за по-нататъшно увеличаване на натоварването и изискванията за надеждност и време между откази, както и GosSvyazNadzor, сертифицираното сървърно оборудване от Aquarius беше закупени.

Съществуващата мрежа активно използва операционната система Debian, базирана на ядрото на Linux; има богат опит в използването на тази система и повечето операции за управление, конфигуриране и осигуряване на стабилността на нейната работа са отстранени. В допълнение, тази ОС се разпространява под GPL лиценз, което показва, че е безплатна и с отворен код, което съответства на актуализираните технически спецификации за проектиране на система за наблюдение на мрежата (пълното име GNU/Linux, произнася се „gnu slash lee ” ́ Nux", също на някои езици "GNU+Linux", "GNU-Linux" и т.н.) е общото име за UNIX-подобни операционни системи, базирани на ядрото със същото име и библиотеки и системни програми, компилирани за него , разработен в рамките на проекта GNU./ Linux работи на PC-съвместими системи от фамилията Intel x86, както и IA-64, AMD64, PowerPC, ARM и много други.

Операционната система GNU/Linux също често включва програми, които допълват тази операционна система и приложни програми, които я превръщат в пълноценна многофункционална операционна среда.

За разлика от повечето други операционни системи, GNU/Linux няма нито един „официален“ пакет. Вместо това GNU/Linux идва в голям брой така наречени дистрибуции, които обединяват GNU програми с ядрото на Linux и други програми. Най-известните GNU/Linux дистрибуции са Ubuntu, Debian GNU/Linux, Red Hat, Fedora, Mandriva, SuSE, Gentoo, Slackware, Archlinux. Руски дистрибуции - ALT Linux и ASPLinux.

За разлика от Microsoft Windows(Windows NT), Mac OS (Mac OS X) и търговски UNIX-подобни системи, GNU/Linux няма географски център за разработка. Няма организация, която да притежава тази система; Дори няма нито един координационен център. Програмите за Linux са резултат от работата на хиляди проекти. Някои от тези проекти са централизирани, други са концентрирани във фирми. Много проекти обединяват хакери от цял ​​свят, които се познават само чрез кореспонденция. Всеки може да създаде свой собствен проект или да се присъедини към съществуващ и, ако успее, резултатите от работата ще станат известни на милиони потребители. Потребителите участват в тестването на безплатен софтуер и комуникират директно с разработчиците, което им позволява бързо да намират и коригират грешки и да внедряват нови функции.

История на развитието на UNIX системите. GNU/Linux е UNIX-съвместим, но се основава на собствен изходен код

Именно тази гъвкава и динамична система за разработка, невъзможна за проекти със затворен код, определя изключителната икономическа ефективност на GNU/Linux. Ниска цена на безплатна разработка, добре установени механизми за тестване и разпространение, привличане на хора от различни странис различни визии за проблемите, защита на кода под лиценза GPL - всичко това стана причина за успеха на свободния софтуер.

Разбира се, такава висока ефективност на разработката не можеше да не заинтересува големите компании, които започнаха да отварят свои собствени проекти. Така се появяват Mozilla (Netscape, AOL), OpenOffice.org (Sun), безплатен клонинг на Interbase (Borland) - Firebird, SAP DB (SAP). IBM помогна за въвеждането на GNU/Linux в своите мейнфрейми.

От друга страна, отвореният код значително намалява разходите за разработване на затворени системи за GNU/Linux и позволява цената на решението да бъде намалена за потребителя. Ето защо GNU/Linux се превърна в платформата, която често се препоръчва за продукти като Oracle DBMS, DB2, Informix, SyBase, SAP R3, Domino.

GNU/Linux общността комуникира чрез Linux потребителски групи.

Повечето потребители използват комплекти за разпространение, за да инсталират GNU/Linux. Дистрибуцията не е просто набор от програми, а поредица от решения за различни потребителски задачи, обединени унифицирани системиинсталиране, управление и актуализации на пакети, конфигурация и поддръжка.

Най-разпространените дистрибуции в света: - дистрибуция, която бързо набира популярност, фокусирана върху лекотата на изучаване и използване - свободно разпространявана версия на дистрибуцията SuSE, собственост на компанията Novell. Лесно се настройва и поддържа благодарение на използването на помощната програма YaST - поддържана от общността и корпорацията RedHat, предхождаща пускането на комерсиалната версия на RHEL - международна дистрибуция, разработена от голяма общност разработчици за некомерсиални цели. Послужи като основа за създаването на много други дистрибуции. Отличава се със строг подход към включването на патентован софтуер - френско-бразилска дистрибуция, обединение на бившия Mandrake и Conectiva (на английски език) - една от най-старите дистрибуции, отличаваща се с консервативен подход в разработката и използването. Разпределение, компилирано от изходни кодове. Тя ви позволява да персонализирате крайната система много гъвкаво и да оптимизирате производителността, поради което често се нарича мета-дистрибуция. Насочена към експерти и опитни потребители - Фокусирана върху използването на най-новите версии на програми и постоянно актуализирана, поддържаща както бинарни, така и изходни инсталации и изградена върху философията на KISS за простота, тази дистрибуция е насочена към компетентни потребители, които искат да имат цялата мощ. и Linux може да се променя, без да се жертва време за поддръжка.

В допълнение към изброените има много други дистрибуции, както базирани на изброените, така и създадени от нулата и често предназначени да изпълняват ограничен брой задачи.

Всеки от тях има своя собствена концепция, собствен набор от пакети, своите предимства и недостатъци. Никой не може да задоволи всички потребители и затова наред с лидерите има други компании и асоциации на програмисти, които предлагат своите решения, своите дистрибуции, своите услуги. Има много LiveCD, създадени на GNU/Linux, като Knoppix. LiveCD ви позволява да стартирате GNU/Linux директно от компактдиск, без да го инсталирате на вашия твърд диск.

За тези, които искат да разберат напълно GNU/Linux, всяка от дистрибуциите е подходяща, но доста често за тази цел се използват така наречените базирани на източника дистрибуции, тоест те включват самостоятелно сглобяване на всички (или част) от компоненти от изходни кодове, като LFS, Gentoo, ArchLinux или CRUX.

4.1 Инсталиране на системното ядро

Nagios може да се инсталира по два начина - от сорс код и от компилирани пакети. И двата метода имат предимства и недостатъци, нека ги разгледаме.

Плюсове от инсталирането на техния пакет с изходен код:

§ възможност за детайлна конфигурация на системата;

§ висока степен на оптимизация на приложението;

§ най-пълното представяне на работата на програмата.

Недостатъци на инсталирането на техния пакет с изходен код:

§ необходимо е допълнително време за сглобяване на пакета, което често надвишава времето за неговото конфигуриране и настройка;

§ невъзможност за премахване на пакета заедно с конфигурационните файлове;

§ невъзможност за актуализиране на пакета заедно с конфигурационните файлове;

§ невъзможност за централизиран контрол върху инсталираните приложения.

Когато инсталирате Nagios от предварително изграден пакет, предимствата на метода на необработената инсталация се превръщат в недостатъци и обратното. Въпреки това, както показва практиката, предварително сглобеният пакет отговаря на всички изисквания за системата и няма смисъл да губите време за ръчно сглобяване на пакета.

Тъй като и двата метода на инсталиране бяха първоначално тествани, ще разгледаме всеки от тях по-подробно.

4.1.1 Описание на инсталирането на системата на ядрото на техните изходни кодове

Необходими пакети.

Трябва да се уверите, че следните пакети са инсталирани, преди да разположите Nagios. Подробното разглеждане на инсталационния процес е извън обхвата на тази работа.

· Apache 2

· PHP

· GCC компилатор и библиотеки за разработка

· GD библиотеки за разработчици

Можете да използвате помощната програма apt-get (за предпочитане aptitude), за да ги инсталирате, както следва:

% sudo apt-get инсталирайте apache2

% sudo apt-get инсталирайте libapache2-mod-php5

% sudo apt-get install build-essential

% sudo apt-get инсталирайте libgd2-dev

1) Създайте нов потребителски непривилегирован акаунт

Създава се нов акаунт за стартиране на услугата Nagios. Можете също да направите това от акаунт на суперпотребител, което ще представлява сериозна заплаха за сигурността на системата.

Нека станем суперпотребител:

Нека създадем нов потребителски акаунт на nagios и да му дадем парола:

# /usr/sbin/useradd -m -s /bin/bash nagios

# passwd nagios

Нека създадем групата nagios и добавим потребителя nagios към нея:

# /usr/sbin/groupadd нагиос

# /usr/sbin/usermod -G nagios nagios

Нека създадем група nagcmd, за да позволим изпълнението на външни команди, изпратени през уеб интерфейса. Нека добавим потребители на nagios и apache към тази група:

# /usr/sbin/groupadd nagcmd

# /usr/sbin/usermod -a -G nagcmd nagios

# /usr/sbin/usermod -a -G nagcmd www-данни

2) Изтеглете Nagios и неговите добавки

Нека създадем директория за съхраняване на изтеглените файлове:

# mkdir ~/изтегляния

# cd ~/изтегляния

Изтеглете компресираните изходни кодове на Nagios и неговите добавки (#"justify"># wget #"justify"># wget #"justify">3) Компилирайте и инсталирайте Nagios

Нека разопаковаме компресираните изходни кодове на Nagios:

# cd ~/изтегляния

# tar xzf nagios-3.2.0.tar.gz

# cd nagios-3.2.0

Изпълняваме конфигурационния скрипт на Nagios, като му предаваме името на групата, която създадохме по-рано:

# ./configure --with-command-group=nagcmd

Пълен списъкпараметри на конфигурационния скрипт:

#./configure --help

`configure" конфигурира този пакет да се адаптира към много видове системи.: ./configure ... ...задайте променливи на средата (напр. CC, CFLAGS...), укажете ги като=VALUE. Вижте по-долу за описания на някои на полезните променливи.за опциите са посочени в скоби.:

h, --help показва тази помощ и излиза

Помощ=кратки опции за показване, специфични за този пакет

Помощ=рекурсивно показване на кратката помощ на всички включени пакети

V, --version показване на информация за версията и изход

q, --quiet, --silent не отпечатвайте съобщения „проверка...”.

Cache-file=FILE кеш тестови резултати във FILE

C, псевдоним --config-cache за `--cache-file=config.cache"

n, --no-create не създава изходни файлове

Srcdir=DIR Намерете източниците в DIR директории:

Prefix=PREFIX инсталиране на независими от архитектурата файлове в PREFIX

Exec-prefix=EPREFIX инсталира зависими от архитектурата файлове в EPREFIXпо подразбиране, `make install" ще инсталира всички файлове в `/usr/local/nagios/bin", `/usr/local/nagios/lib" и т.н. Можете да посочите инсталационен префикс, различен от `/usr/local/nagios", използвайки `--prefix", например `--prefix=$HOME". по-добър контрол, използвайте опциите по-долу. настройка на инсталационните директории:

Bindir=DIR потребителски изпълними файлове

Sbindir=DIR системни административни изпълними файлове

Libexecdir=Изпълними файлове на DIR програма

Datadir=DIR данни само за четене, независими от архитектурата

Sysconfdir=DIR данни само за четене на една машина

Sharedstatedir=DIR модифицируеми независими от архитектурата данни

Localstatedir=DIR модифицируеми данни за една машина

Libdir=DIR библиотеки с обектен код

Includedir=DIR C заглавни файлове

Oldincludedir=DIR C заглавни файлове за не-gcc

Infodir=Информационна документация за DIR

Mandir=DIR man типове документация:

Build=BUILD конфигуриране за изграждане на BUILD

Host=HOST кръстосано компилиране за изграждане на програми, които да работят на HOST Характеристики:

Disable-FEATURE не включва FEATURE (същото като --enable-FEATURE=no)

Enable-FEATURE[=ARG] включва FEATURE

Disable-statusmap=забранява компилирането на CGI карта на състоянието

Disable-statuswrl=забранява компилирането на statuswrl (VRML) CGI

Enable-DEBUG0 показва влизане и излизане от функцията

Enable-DEBUG1 показва общи информационни съобщения

Enable-DEBUG2 показва предупредителни съобщения

Enable-DEBUG3 показва планирани събития (сервизни и хост проверки... и т.н.)

Enable-DEBUG4 показва известия за услуга и хост

Enable-DEBUG5 показва SQL заявки

Enable-DEBUGALL показва всички съобщения за отстраняване на грешки

Enable-nanosleep позволява използването на nanosleep (вместо сън) във времето на събитието

Enable-event-broker позволява интегриране на съчетания на посредника на събития

Enable-embedded-perl ще активира вградения интерпретатор на Perl

Enable-cygwin позволява изграждане под средата на CYGWIN Пакети:

С-PACKAGE[=ARG] използвайте PACKAGE

Без-PACKAGE не използвайте PACKAGE (същото като --with-PACKAGE=no)

With-nagios-user= задава потребителско име за стартиране на nagios

With-nagios-group= задава име на група за изпълнение на nagios

With-command-user= задава потребителско име за команден достъп

With-command-group= задава име на група за команден достъп

С-поща= Задава път към еквивалентна програма на mail

With-init-dir= Задава директория, в която да постави началния скрипт

С-lockfile= Задава път и име на файл за заключващ файл

With-gd-lib=DIR задава местоположението на gd библиотеката

With-gd-inc=DIR задава местоположението на включените gd файлове

С-cgiurl= задава URL за cgi програми (не използвайте наклонена черта в края)

С-htmurl= задава URL за обществен html

With-perlcache включва кеширане на вътрешно компилирани Perl скриптове, влиятелни променливи на обкръжението:C компилатор командаC компилатор flagslinker флагове, напр. -Л ако имате библиотеки в директория C/C++ флагове за препроцесор, напр. -Аз ако имате в нестандартна директория C препроцесорни променливи, за да отменят изборите, направени от „configure“ или да помогнат за намиране на библиотеки и програми с нестандартни имена/локации.

Компилиране на изходния код на Nagios.

Да инсталираме двоични файлове, скрипт за инициализация, примери за конфигурационни файлове и задаване на разрешения за директорията с външни команди:

# make install-init

# make install-config

# make install-commandmode

) Да променим конфигурацията

Примерните конфигурационни файлове са инсталирани в директорията /usr/local/nagios/etc. Те трябва да работят веднага. Трябва да направите само една промяна, преди да продължите.

Нека редактираме конфигурационния файл /usr/local/nagios/etc/objects/contacts.cfg с произволен текстов редактори променете имейл адреса, свързан с дефиницията за контакт на nagiosadmin, на адреса, на който ще получаваме съобщения за проблеми.

# vi /usr/local/nagios/etc/objects/contacts.cfg

5) Настройка на уеб интерфейса

Нека инсталираме конфигурационния файл на уеб интерфейса на Nagios в директорията conf.d на Apache.

# make install-webconf

Нека създадем nagiosadmin акаунт, за да влезем в уеб интерфейса на Nagios

# htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

Нека рестартираме Apache, за да влязат в сила промените.

# /etc/init.d/apache2 презареждане

Необходимо е да се вземат мерки за укрепване на сигурността на CGI, за да се предотврати кражбата на този акаунт, тъй като информацията за наблюдение е доста чувствителна.

) Компилирайте и инсталирайте Nagios добавки

Нека разопаковаме компресираните изходни кодове на Nagios добавки:

# cd ~/изтегляния

# tar xzf nagios-plugins-1.4.11.tar.gz

Компилирайте и инсталирайте добавки:

# ./configure --with-nagios-user=nagios --with-nagios-group=nagios

#make install

) Стартирайте услугата Nagios

Нека конфигурираме Nagios да се зарежда автоматично, когато операционната система е включена:

# ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios

Нека проверим синтактичната коректност на примерните конфигурационни файлове:

# /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

Ако няма грешки, стартирайте Nagios:

# /etc/init.d/nagios стартиране

) Влезте в уеб интерфейса

Вече можете да влезете в уеб интерфейса на Nagios, като използвате следния URL адрес. Ще бъдете подканени да въведете потребителското име (nagiosadmin) и паролата, които сме задали по-рано.

#"justify">) Други настройки

За да получавате напомняния по имейл за събития на Nagios, трябва да инсталирате пакета mailx (Postfix):

% sudo apt-get инсталирайте mailx

% sudo apt-get install postfix

Трябва да редактирате командите за напомняне на Nagios във файла /usr/local/nagios/etc/objects/commands.cfg и да промените всички връзки от "/bin/mail" на "/usr/bin/mail". След това трябва да рестартирате услугата Nagios:

# sudo /etc/init.d/nagios рестартирайте

Подробната конфигурация на пощенския модул е ​​описана в Приложение D.

4.1.2 Описание на инсталирането на системното ядро ​​от хранилището

Както е показано по-горе, инсталирането на Nagios от източника отнема значително време и има смисъл само ако се нуждаете от внимателна оптимизация на приложението или искате да разберете напълно механизма на системата. В производствените среди повечето софтуер се инсталира от хранилища като предварително компилирани пакети. В този случай инсталацията се свежда до въвеждане на една команда:

% sudo aptitude инсталирате nagios

Мениджърът на пакети независимо ще задоволи всички зависимости и ще инсталира необходимите пакети.

4.2 Конфигуриране на ядрото на системата

Преди подробни настройкиТрябва да разберете как работи ядрото на Nagios. Неговото графично описание е дадено по-долу в илюстрация 6.2.

4.2.1 Описание на работата на системното ядро

Следващата фигура показва опростена диаграма на това как работи услугата Nagios.

Ориз. 4.1 - Ядро на системата

Услугата Nagios чете основния конфигурационен файл, който в допълнение към основните параметри за услугата съдържа връзки към файлове с ресурси, файлове с описание на обекти и CGI конфигурационни файлове.

Алгоритъмът и логиката на ядрото за наблюдение на мрежата са показани по-долу.

Ориз. 4.2 - Алгоритъм за предупреждение на Nagios

2.2 Описание на взаимодействието на конфигурационните файлове

Директорията /etc/apache2/conf.d/ съдържа файла nagios3.conf, от който уеб сървърът на apache взема настройките за nagios.

Конфигурационните файлове на Nagios се намират в директорията /etc/nagios3.

Файлът /etc/nagios3/htpasswd.users съдържа пароли за потребителите на nagios. Командата за създаване на файла и задаване на парола по подразбиране за потребителя nagios е дадена по-горе. В бъдеще ще трябва да пропуснете аргумента "-c", когато задавате парола за нов потребител, в противен случай нов файлстарата ще бъде изтрита.

Файлът /etc/nagios3/nagios.cfg съдържа основната конфигурация на самия nagios. Например, регистрационни файлове на събития или път до други конфигурационни файлове, които nagios чете при стартиране.

Новите хостове и услуги са посочени в директорията /etc/nagios/objects.

4.2.3 Попълване на описания на хост и услуги

Както е показано по-горе, можете да конфигурирате ядрото на системата, като използвате един файл с описание за хостове и услуги, но този метод няма да е удобен, тъй като броят на наблюдаваното оборудване се увеличава, така че е необходимо да се създаде определена структура от директории и файлове с описания на домакини и услуги.

Създадената структура е показана в Приложение H.

Hosts.cfg файл

Първо трябва да опишете хостовете, които ще бъдат наблюдавани. Можете да опишете колкото искате хостове, но в този файл ще се ограничим до общи параметри за всички хостове.

Тук описаният хост не е истински хост, а шаблон, на който са базирани описанията на всички други хостове. Същият механизъм може да бъде намерен в други конфигурационни файлове, където конфигурацията се основава на предварително зададен набор от стойности по подразбиране.

Hostgroups.cfg файл

Тук хостовете се добавят към хост групата. Дори в проста конфигурация, когато има само един хост, все пак трябва да го добавите към група, така че Nagios да знае коя група контакти да използва за изпращане на предупреждения. Повече подробности за контактната група по-долу.

Файл contactgroups.cfg

Дефинирахме група контакти и добавихме потребители към тази група. Тази конфигурация гарантира, че всички потребители получават предупреждение, ако нещо не е наред със сървърите, за които отговаря групата. Трябва обаче да имате предвид, че индивидуалните настройки за всеки потребител могат да заменят тези настройки.

Следващата стъпка е да посочите информация за контакт и настройки за предупреждения.

Файл contacts.cfg

В допълнение към факта, че този файл предоставя допълнителни Информация за връзкапотребители, едно от полетата, contact_name, има друга цел. CGI скриптовете използват имената, посочени в тези полета, за да определят дали даден потребител има разрешение за достъп до ресурс или не. Трябва да конфигурирате удостоверяване на базата на .htaccess, но също така трябва да използвате същите имена като по-горе, за да могат потребителите да работят през уеб интерфейса.

Сега, когато хостовете и контактите са конфигурирани, можете да преминете към настройка на наблюдение на отделни услуги, които трябва да бъдат наблюдавани.

Services.cfg файл

Тук, както във файла hosts.cfg за хостове, задаваме само Общи параметриза всички услуги.

Налични са огромен брой допълнителни Nagios модули, но ако все още няма отметка, винаги можете да я напишете сами. Например, няма модул, който да проверява дали Tomcat работи или не. Можете да напишете скрипт, който зарежда JSP страница от отдалечен Tomcat сървър и връща резултата в зависимост от това дали заредената страница има текст на страницата или не. (Когато добавяте нова команда, трябва да я споменете във файла checkcommand.cfg, който не сме докоснали).

След това за всеки отделен хост създаваме собствен файл с описание, в същия файл ще съхраняваме описания на услугите, които ще наблюдаваме за този хост. Това се прави за удобство и логическа организация.

Струва си да се отбележи, че хостовете на Windows се наблюдават чрез протокола SNMP и NSClient a, който идва с Nagios. По-долу има диаграма на работата му

Ориз. 4.3 - Схема за мониторинг на Windows хост

В същото време *nix хостове също се наблюдават чрез SNMP, както и плъгина NRPE. Диаграмата на неговата работа е показана на фигурата

Ориз. 4.4 - Схема за наблюдение за *nix хостове

2.4 Писане на добавки

В допълнение към писането на скриптове за инициализация, дефиниране на хостове и услуги, бяха използвани следните добавки:

├── проверка_диск

├── check_dns

├── проверка_http

├── проверка_icmp

├── check_ifoperstatus

├── check_ifstatus

├── check_imap -> check_tcp

├── check_linux_raid

├── проверка_зареждане

├── check_mrtg

├── check_mrtgtraf

├── проверка_nrpe

├── check_nt

├── check_ping

├── check_pop -> check_tcp

├── проверка_сензори

├── check_simap -> check_tcp

├── проверка_smtp

├── check_snmp

├── check_snmp_load.pl

├── check_snmp_mem.pl

├── check_spop -> check_tcp

├── check_ssh

├── check_ssmtp -> check_tcp

├── check_swap

├── проверка_tcp

├── време за проверка

Повечето от тях идват с пакета Nagios. Изходните текстове на плъгини, които не са включени в комплекта за доставка и се използват в системата, са представени в Приложение I.

4.2.5 Конфигуриране на SNMP на отдалечени хостове

За да можете да наблюдавате с помощта на протокола SNMP, първо трябва да конфигурирате агенти за този протокол на вашето мрежово оборудване. Диаграмата за това как SNMP работи във връзка с ядрото на системата за наблюдение на мрежата е показана на фигурата по-долу.

Ориз. 4.5 - Схема за наблюдение по SNMP протокол

Конфигурационните параметри на хоста са представени в Приложение 3. Сигурността се постига чрез индивидуално конфигуриране на филтър за пакети на всеки хост поотделно и чрез организиране на защитени системни подмрежи, до които само оторизиран персонал на предприятието има достъп. Освен това конфигурацията е направена по такъв начин, че с помощта на SNMP протокола можете само да четете параметри, но не и да ги записвате.

4.2.6 Конфигуриране на агента на отдалечени хостове

За да получите разширени възможности за наблюдение на хостове и услуги, трябва да инсталирате агента Nagios върху тях, който се нарича nagios-nrpe-сървър:

# aptitude инсталира nagios-nrpe-сървър

Конфигурацията на агента е представена в Приложение L. Диаграмата на работата на агента е показана на Фигура 4.5 по-горе.

4.4 Инсталиране и конфигуриране на модула за проследяване на изтегляне

MRTG (Multi Router Traffic Grapher) е услуга, която ви позволява да получавате информация от няколко устройства, използващи протокола SNMP, и да показвате графики за натоварване на канала (входящ трафик, изходящ трафик, максимален, среден) на стъпки от минути, часове, дни и години в прозореца на вашия браузър.

Изисквания за инсталиране

За да работи MRTG, са необходими следните библиотеки:

§ gd - библиотека за чертане на графики. Библиотека, отговорна за генериране на графики (#"justify">§ libpng - gd е необходим за създаване на графики в png формат (#"justify">В нашия случай инсталацията се свежда до изпълнение на една команда, тъй като избраният метод е да се инсталира предварително компилиран пакет от хранилището:

# aptitude инсталирате mrtg

Можете да създавате конфигурационни файлове ръчно или можете да използвате конфигурационните генератори, включени в пакета:

#cfgmaker @ >

След генериране на конфигурационния файл се препоръчва да го проверите, т.к може да съдържа описания на интерфейси, които не е необходимо да анализираме за натоварване. В този случай определени редове във файла се коментират или изтриват. Пример за конфигурационен файл на MRTG е предоставен в Приложение M. Поради големия размер на тези файлове е предоставен само пример за един файл.

#производител на индекси >

Индексните страници са обикновени html файлове и тяхното съдържание не представлява особен интерес, така че няма смисъл да даваме примери за тях. Приложение H показва пример за показване на графики за натоварване на интерфейса.

И накрая, необходимо е да се организира проверка на натоварването на интерфейса по график. Най-лесният начин да постигнете това е да използвате операционната система, а именно параметрите на crontab.

4.5 Инсталиране и конфигуриране на модула за събиране на журнали на системни събития

Пакетът syslog-ng.ng (следващо поколение syslog) беше избран като модул за събиране на регистрационни файлове на системни събития - това е многофункционална услуга за регистриране на системни съобщения. В сравнение със стандартната услуга syslogd, тя има редица разлики:

§ подобрена конфигурационна диаграма

§ филтриране на съобщения не само по приоритет, но и по тяхното съдържание

§ поддръжка на регулярни изрази (регулярни изрази)

§ по-гъвкаво манипулиране и организиране на дневници

§ възможност за криптиране на канала за предаване на данни с помощта на IPSec/Stunnel

Следната таблица показва поддържаните хардуерни платформи.

Таблица 4.1 - Поддържани хардуерни платформи

x86x86_64SUN SPARCppc32ppc64PA-RISCAIX 5.2 & 5.3НеНеНеДаПри заявкаНеDebian etchДаНеНеНеНеFreeBSD 6.1 *ДаПри заявкаНеНеНеHP-UNo 11iНеНеНеНеНеДаIBM System iNoНеНеДаНеНеRed Hat ES 4 / CentOS 4ДаДаНеНеНеНеR ed Hat ES 5 / CentOS 5ДаДаНеНеНеNoSLES 10 / openSUSE 10.0ДаПри поискванеНеНеНеNoSLES 10 SP1 / openSUSE 10.1ДаДаНеНеНеНеНеSolaris 8НеНеДаНеНеНеНеSolaris 9При поискванеНеДаНеНеНеНеSolaris 10 При поискванеДаДаНеНеНеНеWindowsДаДаНеНеНеНеНе Забележка: *Достъпът до базата данни на Oracle не се поддържа

Подробно сравнение технически характеристикие дадено в Приложение П.

Файлове, описващи правила и филтри, както и конфигурацията на отдалечени хостове са дадени в Приложение P.

Има RFC документ, който описва протокола на syslog като цяло, работата на модула за събиране на системни журнали може да бъде представена чрез следната диаграма

Ориз. 4.6 - Схема на работа на модула за събиране на системни журнали

На клиента хост всеки отделно приложениезаписва свой собствен регистър на събитията, като по този начин формира източник. След това потокът от съобщения за регистрационни файлове преминава през определяне на мястото за съхранение, след което чрез филтри се определя неговата мрежова посока, след което при достигане на сървъра за регистриране отново се определя мястото за съхранение за всяко съобщение. Избраният модул има голяма мащабируемост и възможности за сложна конфигурация, например филтрите могат да бъдат разклонени, така че съобщенията за системни събития да се изпращат в няколко посоки в зависимост от няколко условия, както е показано на фигурата по-долу.

Ориз. 4.7 - Разклонени филтри

Възможността за мащабиране означава, че за да разпредели натоварването, администраторът ще разположи мрежа от спомагателни филтриращи сървъри, така наречените релета.

Ориз. 4.8 - Мащабиране и балансиране на натоварването

В крайна сметка, по най-опростен начин, работата на модула може да се опише по следния начин: клиентските хостове предават съобщения за регистър на събития от различни приложения към разтоварващи сървъри, които от своя страна могат да ги предават по верига от релета и така нататък до централните сървъри за събиране.

Ориз. 4.9 - Обобщена схема на работа на модула

В нашия случай потокът от данни не е толкова голям, че да разгърне система за разтоварване на сървъри, така че беше решено да се използва опростена схема на работа клиент-сървър.

Ориз. 4.10 - Приета работна схема

5. РЪКОВОДСТВО НА СИСТЕМНИЯ АДМИНИСТРАТОР

Като цяло се препоръчва системният администратор да се придържа към съществуващата йерархия от конфигурационни файлове и директории. Добавянето на нови хостове и услуги към системата за мониторинг се свежда до създаване на нови конфигурационни файлове и скриптове за инициализация, както беше показано в Раздел 5 - Разработка на софтуер, така че няма смисъл да се описват отново параметрите и принципите на конфигуриране на системата в тази работа , но си струва да разгледаме по-подробно описанието на интерфейсите на отделните системни модули.

5.1 Описание на уеб интерфейса на системата

За да се извършва интерактивен мониторинг на услугите, беше по-удобно да се интегрира уеб интерфейс в системата. Уеб интерфейсът също е добър, защото дава пълна картина на системата благодарение на умелото използване на графични инструменти и предоставянето на допълнителна статистическа информация.

Когато влезете в уеб страницата на Nagios, ще бъдете помолени да въведете потребителското име и паролата, които сме задали по време на процеса на настройка. начална страницауеб интерфейсът е показан на фигурата по-долу.

Ориз. 5.1 - Начална страница на уеб интерфейса на системата

Отляво е навигационна лента,Вдясно са резултатите от различните изгледи на данните за състоянието на мрежата, хоста и услугата. Ще се интересуваме преди всичко от раздел Мониторинг. Нека да разгледаме страницата Тактически преглед.

Ориз. 5.2 - Начална страница на уеб интерфейса на системата

Тази страница съдържа обобщена информация за всички параметри за наблюдение и състоянието на хостовете и услугите, но ако възникнат проблеми, те се маркират със специален цвят и се превръщат в хипервръзка, водеща до подробно описание на проблема, който е възникнал. възникнал. В нашия случай в момента има един неразрешен проблем сред всички хостове и услуги, следвайте тази връзка (1 Необработени проблеми).

Ориз. 5.3 - Открит сервизен проблем

Тук виждаме в таблична форма на кой хост е възникнал проблемът, коя услуга го е причинила (в нашия случай това е високо натоварване на процесора на рутера), състоянието на грешката (може да бъде нормално, прагово и критично), времето на последното проверка, продължителността на проблема, номер на проверка на сметката в цикъла и подробна информациясъс специфични стойности, върнати от използвания плъгин.

Ориз. 5.4 - Подробно описание на състоянието на услугата

Тук виждаме пълно описание на проблема, тази страница е полезна за задълбочен анализ на проблема, когато причината за възникването му не е напълно ясна, например може да е в твърде строго определени прагове на критичност на състоянието или неправилно дадени параметристартиране на плъгина, което също ще бъде оценено от системата като критично състояние. В допълнение към описанието, от тази страница можете да изпълнявате команди на услугата, например да деактивирате проверките, да насрочите различно време за следващата проверка, да приемете данни пасивно, да приемете проблема за разглеждане, да деактивирате предупреждения, да изпратите предупреждение ръчно, планирайте прекъсване на услугата, деактивирайте откриването на нестабилно състояние и напишете коментар.

Да отидем на страницата с подробности за услугата.

Ориз. 5.5 - Детайлен преглед на всички услуги

Тук виждаме списък с всички хостове и услуги, независимо от текущото им състояние. Тази функция може да е полезна, но преглеждането на дълъг списък с хостове и услуги не е много удобно и е необходимо по-скоро за визуализиране от време на време на обема работа, извършена от системата. Тук всеки хост и услуга, както на Фигура 6.3, е връзка, водеща към по-подробно описание на параметъра.

Ориз. 5.6 - Пълен подробен списък на хостове

Тази таблица предоставя пълен подробен списък на хостовете, техните статуси, последно време на проверка, продължителност на текущия статус и Допълнителна информация. В нашата система е прието статусът на хоста да се проверява чрез проверка на наличността на хоста чрез ICMP протокола (8), тоест командата ping, но в общ случайпроверката може да бъде всякаква. Иконите в колоната вдясно от името на хоста показват групата, към която принадлежи, това се прави за по-лесно възприемане на информацията. Иконата на светофара е връзка, водеща към подробен списък с услуги на даден хост; няма смисъл да описваме тази таблица отделно, тя е точно същата като на Фигура 10.4, само информацията е представена за един хост.

Следните връзки в списъка са различни модификации на предишните таблици и разбирането на тяхното съдържание няма да е трудно. Най-интересната функция на уеб интерфейса е възможността за изграждане на мрежова карта в полуавтоматичен режим.

Ориз. 5.7 - Пълна кръгова мрежова карта

Чрез родителския параметър на всеки хост и услуга можем да създадем структурата или йерархията на нашата мрежа, която ще определи логиката на ядрото за наблюдение на мрежата и представянето на хостове и услуги на мрежовата карта. Има няколко режима на показване, като освен кръгъл, най-удобни са балансираният дървовиден и сферичният режим.

Ориз. 5.8 - Карта на мрежата - режим на балансирано дърво

Ориз. 5.9 - Карта на мрежата - режим топка

Във всички режими изображението на всеки хост е връзка към неговата таблица с услуги и техните състояния.

Следващата важна част от основния интерфейс за наблюдение е създателят на тенденции. С негова помощ можете да планирате подмяната на оборудването с по-продуктивно, нека дадем пример. Кликнете върху връзката Тенденции. Изберете вида отчет - услуга.

Стъпка 1: Изберете Тип отчет: Услуга

Третата стъпка е да изберете периода на броене и да генерирате отчет.

Ориз. 5.10 - Тенденция

Ние генерирахме тенденция на натоварване на процесора при маршрутизиране. От това можем да заключим, че в продължение на месец този параметър непрекъснато се влошава и е необходимо сега да се вземат мерки или за оптимизиране на работата на хоста, или за подготовка за замяната му с по-производителен.

5.2 Описание на уеб интерфейса на модула за проследяване на зареждането на интерфейса

Уеб интерфейсът на модула за проследяване на зареждането на интерфейса е списък от директории, в които са разположени индексните страници на наблюдаваните хостове с графики за зареждане за всеки интерфейс.

Ориз. 5.11 - Начална страница на модула за проследяване на зареждането на интерфейса

Щраквайки върху някоя от връзките, ще получим зареждащи се графики. Всяка графика е връзка, водеща към статистика за седмицата, месеца и годината.

5.3 Описание на модула за събиране на журнали на системни събития

В момента не се изисква подобрено филтриране на системни регистрационни файлове и възможност за търсене в тях чрез един уеб интерфейс, т.к. Проблеми, изискващи преглед на тези регистрационни файлове, възникват доста рядко. Поради това разработването на база данни за тези регистрационни файлове и уеб интерфейс беше отложено. В момента те са достъпни чрез ssh и сърфиране в директория в mc файловия мениджър.

В резултат на този модул получихме следната структурадиректории:

├── apache2

├── астерикс

├── bgp_router

├── dbconfig-common

├── инсталатор

│ └── cdebconf

├── len58a_3lvl

├── мониторинг

├──nagios3

│ └── архиви

├── ocsinventory-клиент

├── ocsinventory-сървър

├── куага

├── router_krivous36b

├── router_lenina58a

├── router_su

├── router_ur39a

├── оформител

├── ub13_рутер

├── univer11_router

└── VoIP

Всяка директория е хранилище на журнали на събития за всеки отделен хост.

Ориз. 5.13 - Преглед на данни, събрани от модула за събиране на системни събития

6. ТЕСТВАНЕ НА ЕКСПЛОАТАЦИЯТА

При внедряването на системата е извършено поетапно тестване на работата на всеки компонент, като се започне от ядрото на системата. Разширяването на функционалността е извършено едва след окончателната настройка на по-ниските нива на модулите на системата за мониторинг на мрежата в йерархията поради многото зависимости на различните подсистеми. Стъпка по стъпка, като цяло, процесът на внедряване и тестване може да се опише по следния начин:

) Инсталиране и конфигуриране на базираното на Nagios ядро;

) Настройка на мониторинг на отдалечени хостове с помощта на основна функционалност на Nagios;

) Настройка на модул за наблюдение на натоварването на мрежовите интерфейси с помощта на MRTG;

) Разширяване на функционалността на системното ядро ​​и интегрирането му с MRTG модула;

) Настройка на модул за събиране на системни логове;

) Писане на скрипт за инициализиране на филтър за пакети за система за наблюдение, за да се гарантира сигурността на системата.

7. Информационна сигурност

1 Характеристики на работното място

Вредните фактори, влияещи върху работата при използване на компютър, включват:

· повишена стойност на напрежението на електрическия ток;

· шум;

· електромагнитно излъчване;

· електростатично поле.

За да се осигурят най-добрите условия за ефективна и безопасна работа, е необходимо да се създадат условия на труд, които са комфортни и минимизират въздействието на тези вредни фактори. Необходимо е изброените вредни фактори да са в съответствие с установените правила и разпоредби.

7.2 Безопасност на труда

2.1 Електрическа безопасност

Разработеният софтуерен инструмент е създаден за работа на съществуващ сървър, разположен в специално оборудвано техническо помещение. Оборудвана е с кабелни кутии за полагане на кабели. Всеки сървър се захранва със захранване ~220V, честота 50Hz, с работно заземяване. Преди да влезе захранването в помещението, се монтират прекъсвачи, които изключват захранването в случай на късо съединение. Защитното заземяване се извършва отделно.

При свързване на компютър е необходимо корпусът на оборудването да се свърже към защитно заземяване, така че в случай на повреда на изолацията или по някаква друга причина опасното захранващо напрежение, когато човек докосне корпуса на оборудването, да не може да създаде ток от опасна величина през човешкото тяло.

За да направите това, използвайте третия контакт в електрическите контакти, който е свързан към защитния заземителен проводник. Корпусите на оборудването са заземени чрез захранващия кабел по специално предназначен проводник.

Използват се технически мерки за осигуряване на защита срещу токов удар при докосване на тялото на електрическа инсталация в случай на повреда на изолацията на части под напрежение, които включват:

· защитно заземяване;

· защитно заземяване;

· защитно изключване.

7.2.2 Защита от шум

Изследванията показват, че в шумна среда основно се засяга слуховата функция. Но ефектът от шума не се ограничава до ефекта върху слуха. Той причинява забележими промени в редица физиологични психични функции. Шумът има вредно въздействие върху нервната система и намалява скоростта и точността на сензомоторните процеси, а броят на грешките при решаване на интелектуални задачи се увеличава. Шумът има забележим ефект върху вниманието на човека и предизвиква отрицателни емоции.

Основен източник на шум в помещенията, в които се намират компютри, са климатичните съоръжения, печатащата и копирната техника и вентилаторите на охладителните системи в самите компютри.

Следните мерки за контрол на шума се използват активно в производствената зона:

· използване на безшумни охлаждащи механизми;

· изолиране на източниците на шум от околната среда чрез звукоизолация и шумопоглъщане;

· използването на звукопоглъщащи материали за облицовъчни помещения.

На работното място има следните източници на шум:

· системен блок (охладител (25dB), HDD(29dB), захранване (20dB));

· принтер (49dB).

Общият шум L, излъчван от тези устройства, се изчислява по формулата:

където Li е нивото на шума на едно устройство, dB = 10*lg(316.23+794.33+100+79432.82) = 10*4.91 = 49.1 dB

Съгласно SN 2.2.4/2.1.8.562-96 нивото на шума на работното място на математици-програмисти и видеооператори не трябва да надвишава 50 dB.

7.2.3 Защита срещу електромагнитно излъчване

Защитата срещу електромагнитно въздействие се осигурява от екрани с електропроводима повърхност и използването на монитори, оборудвани със система Low Radiation, която минимизира нивото на вредното излъчване, както и монитори с течни кристали, в които електромагнитното излъчване напълно липсва.

7.2.4 Защита срещу електростатични полета

За защита от въздействието на електростатичния заряд се използва заземен защитен филтър, използват се овлажнители на въздуха, а подовете са покрити с антистатично покритие. За поддържане на нормализирани стойности на концентрацията на положителни и отрицателни йони в компютърните зали се монтират климатици и устройства за йонизация на въздуха и се извършва естествена вентилация за най-малко 10 минути след всеки 2 часа работа.

За да се предотврати вредното въздействие на праховите частици, съдържащи аероиноини, върху тялото на работещите, ежедневно се извършва мокро почистване на помещенията и прахът се отстранява от екраните поне веднъж на смяна, когато мониторът е изключен.

7.3 Условия на труд

3.1 Микроклимат на производствените помещения

Оборудването, разглеждано в този дипломен проект, не произвежда никакви вредни вещества по време на работа. По този начин въздушната среда в помещението, където се използват, не оказва вредно въздействие върху човешкото тяло и отговаря на изискванията за работа от категория I, съгласно GOST 12.1.005-88.

Оптималните стандарти за температура, относителна влажност и скорост на въздуха в работната зона на производствените помещения са стандартизирани от GOST 12.1.005-88 и са показани в таблица 7.1.

Таблица 7.1 - Параметри на микроклимата

Стандартизиран параметър Стойност Оптимална Приемлива Действителна Температура на въздуха, C20 - 2218 - 2020 Влажност, %40 - 60 Не повече от 8045 Скорост на движение на въздуха, m/s0,20,30..0,3

Микроклиматът отговаря на оптимални условия.

3.2 Индустриално осветление

За изчислението избираме отдела за поддръжка на Gerkon LLC в град Верхняя Пишма, където се проведе разработването на този проект:

· площта на помещението е 60 м2;

· площ на светлинните отвори 10 m2;

· Инсталирани са 4 автоматизирани работни места.

Естественото осветление се изчислява по формулата SNiP 23.05-95:

S0 = Sp * en * Kz * N0 * KZD / 100% * T0 * T1 (7.2)

Където S0 е площта на светлинните отвори, m2;

Sp - площ на помещението, m2, 60;

en - коефициент на естествена осветеност, 1,6;

Kz - коефициент на безопасност, 1,5;

N0 - светлинни характеристики на прозорците, 1;

KZD - коефициент, отчитащ затъмняването на прозорците от срещуположни сгради, 1,2;

T0 - обща пропускливост на светлина, 0,48;

T1 - коефициент на отражение от повърхността на помещението, 1.2.

Стойностите на всички коефициенти са взети от SNiP 05.23.-95.

В резултат на изчислението получаваме: необходимата площ на светлинните отвори на прозорците е S0 = 3,4 m2. Реалната площ на отворите е 10 m2, което надвишава минимално допустимата площ на светлите отвори за помещения от този тип и е достатъчна през светлата част на денонощието.

Изчисляване на изкуственото осветление за стая, осветена от 15 луминесцентни лампи тип LDTs-60, всяка с мощност 60 W.

Според SNiP 23.05-95 количеството осветеност от флуоресцентни лампи трябва да бъде най-малко 300 lm в хоризонтална равнина за обща система за осветление. Като се вземат предвид визуална работаС висока точност, стойността на осветеност може да бъде увеличена до 1000lm.

Светлинният поток на флуоресцентна лампа се изчислява по формулата от SNiP 23.05.-95:

Phi = En * S * Z * K / N * η (7.3)

Където En - нормализирана осветеност на помещението, лукс, 200;

S - площ на помещението, m2, 60;

Z - коефициент, отчитащ съотношението на средната осветеност към минимума, 1,1;

K - коефициент на безопасност, отчитащ замърсяването на въздуха, 1,3;

N - брой лампи, 15;

η - коефициент на използване светлинен поток, 0,8.

В резултат на това получаваме Phi = 1340lm, общият светлинен поток на всички лампи е 3740lm, следователно лабораторната осветеност е по-висока от минимално допустимата.

7.4 Ергономичност на работното място

4.1 Организация на работното място

В съответствие със SanPiN 2.2.2/4.2.1340-03 VDT (терминал за видео дисплей) трябва да отговаря на следните технически изисквания:

· яркост на осветлението най-малко 100 cd/m2;

· минималният размер на светлинната точка е не повече от 0,1 mm за цветен дисплей;

· контрастът на изображението на знака е най-малко 0,8;

· кадрова честота най-малко 7 kHz

· брой точки не по-малко от 640;

· антирефлексно покритие на екрана;

· размер на екрана най-малко 31 см по диагонал;

· височината на знаците на екрана е най-малко 3,8 mm;

· разстоянието от очите на оператора до екрана трябва да бъде около 40-80 см;

ВДТ трябва да бъде оборудван с въртяща се платформа, позволяваща да се движи в хоризонтални и вертикални равнини в рамките на 130-220 мм и да променя ъгъла на наклона на екрана с 10-15 градуса.

Дипломната работа е изпълнена на компютър с VDT ViewSonic с диагонал 39см. Този монитор е изработен в съответствие с международните стандарти и отговаря на всички горепосочени технически изисквания.

За клавиатурата се прилагат следните изисквания:

· боядисване на тялото в спокойни меки тонове с дифузна светлинна дисперсия;

· матова повърхност с коефициент на отражение 0,4 - 0,6 и без лъскави части, които могат да създават отблясъци;

Проектът е изпълнен на клавиатура на марката Logitech, която отговаря на всички горепосочени изисквания.

Системните модули са инсталирани на работното място, като се има предвид лесният достъп до гъвкави устройства за съхранение магнитни дисковеи удобен достъп до конектори и контроли от задната страна. Наблизо се съхраняват често използвани дискети системна единицав клетка, защитена от прах и електромагнитни въздействия. Принтерът се намира отдясно на потребителя. Отпечатаният текст се вижда от оператора, когато е в основна работна позиция. Чистата хартия и другите необходими консумативи се съхраняват в специални отделения близо до принтера.

Свързващите кабели се полагат в специални канали. Конструкцията на канала трябва да бъде такава, че свързващите конектори да не пречат на отстраняването на кабелите.

За манипулатор тип мишка е осигурена свободна зона на плота отдясно на потребителя, която трябва да бъде идентична по форма и размер с повърхността на екрана.

работно мястооператорът отговаря на изискванията на GOST 12.2.032-78 SSBT.

Пространствената организация на работното място осигурява оптимална работна поза:

· главата е наклонена напред 10 - 20 градуса;

· гърбът има опора, връзката между рамото и предмишницата, както и между бедрото и подбедрицата е прав ъгъл.

Основните параметри на работното място трябва да могат да се регулират. Това гарантира възможността за създаване на благоприятни условия за работа на индивида, като се вземат предвид геоантропометричните характеристики.

Основни параметри на работно място и мебели, оборудвани с персонален компютър (фиг. 7.1)

Ориз. 7.1 - Работно място на компютърен оператор

· седална височина 42 - 45 см;

· височина на клавиатурата от пода 70 - 85см;

· ъгъл на наклон на клавиатурата от хоризонтала 7 - 15 градуса;

· разстоянието на клавиатурата от ръба на масата е 10 - 26 см;

· разстояние от центъра на екрана до пода 90 - 115 см;

· ъгъл на наклон на екрана от вертикала 0 - 30 градуса (оптимално 15);

· разстоянието на екрана от ръба на масата е 50 - 75 см;

· височина на работната повърхност за бележки 74 - 78см;

Работното място е оборудвано с поставка за крака, която се препоръчва за всички видове работа, свързана с продължително седене в седнало положение.

Съгласно SanPiN 2.2.2.542-96 естеството на работата на компютърен оператор се счита за лека и попада в категория 1А.

Почивките се определят на 2 часа от началото на работната смяна и 2 часа след обедната почивка с продължителност 15 минути. По време на регламентираните почивки, за да се намали нервно-емоционалното напрежение, умората и да се премахнат ефектите от физическата активност, се изпълняват комплекси от упражнения.

7.5 Пожарна безопасност

Помещението, в което се извършваше работата по този проект, има категория за пожарна опасност, установена в NPB 105-03 - запалими и незапалими течности, твърди запалими и незапалими вещества и материали, включително прах и влакна, вещества и материали, които могат да взаимодействат с вода, кислороден въздух или само горят помежду си, при условие че помещенията, в които се намират или образуват, не принадлежат към категории А или Б. Сграда за помещения със степен на пожароустойчивост I съгласно SNiP 21-01-97.

В производствената зона се спазват следните правила за безопасност:

· проходите, изходите от помещенията, достъпът до пожарогасително оборудване са свободни;

· оборудването в експлоатация е в изправност и се проверява всеки път преди започване на работа;

· След приключване на работата помещението се оглежда, захранването се изключва и помещението се затваря.

Има два аварийни изхода от сградите. Ширината на аварийния изход (вратата) е 2м. Маршрутите за евакуация използват конвенционални стълби и люлеещи се врати. На стълбищата няма помещения, технологични комуникации, изходи от асансьори или товарни асансьори. Евакуационните пътища са оборудвани както с естествено, така и с изкуствено аварийно осветление.

Основното средство за гасене на пожар в помещението са ръчни пожарогасители с въглероден диоксид, два броя в помещението.

За откриване на начален стадий на пожар и уведомяване на противопожарната служба се използва автоматична и пожароизвестителна система (AFS). Той самостоятелно активира пожарогасителни инсталации, преди пожарът да достигне големи размери и да уведоми градска службапротивопожарна служба.

В допълнение към аварийната пожароизвестителна система, съоръженията за CC трябва да бъдат оборудвани със стационарни пожарогасителни инсталации. Приложения на газови пожарогасителни инсталации, чието действие се основава на бързото запълване на помещението с пожарогасително газово вещество, в резултат на което се намалява съдържанието на кислород във въздуха.

7.6 Аварийни ситуации

В условията на това помещение най-вероятната аварийна ситуация би била пожар. Ако възникне пожар, е необходимо да се евакуира персоналът и да се съобщи за инцидента на пожарната. Планът за евакуация е представен на фигура 7.2.

Ориз. 7.2 - План за евакуация при пожар

8. ИКОНОМИЧЕСКА ЧАСТ

Този раздел обсъжда разходите за разработване на система за наблюдение на мрежата, нейното внедряване и поддръжка, както и свързаните с това материали и оборудване.

Цената на проекта отразява разходите за средства и труд, използвани в процеса на разработка и производство (амортизация, цена на оборудване, материали, гориво, енергия и др.), част от разходите за жив труд (заплати) и разходите закупени системни модули.

В процеса на дейност и увеличаване на обема на предоставяне на услуги възникна проблемът с проактивното откриване на неизправности и слаби места в мрежовата организация, тоест задачата беше да се приложи решение, което да позволи да се предвиди необходимостта от подмяна или надграждане на мрежови секции преди повредите да засегнат работата на абонатните възли.

С растеж клиентска база, и като следствие от броя на активното оборудване, възникна необходимостта от бързо проследяване на състоянието на мрежата като цяло и отделните й елементи в детайли. Преди внедряването на системата за наблюдение на мрежата, мрежовият администратор трябваше да се свърже чрез протоколи telnet, http, snmp, ssh и др. към всеки мрежов възел от интерес и използвайте вградените инструменти за наблюдение и диагностика. В момента капацитетът на мрежата е 5000 порта, 300 комутатора от ниво 2, 15 рутера и 20 вътрешни сървъра.

В допълнение, мрежовите претоварвания и плаващите повреди бяха открити само когато възникнаха сериозни проблеми сред потребителите, което не позволи да се правят планове за надграждане на мрежата.

Всичко това доведе преди всичко до постоянно влошаване на качеството на предлаганите услуги и увеличаване на натоварването на системните администратори и техническата поддръжка на потребителите, което доведе до колосални загуби.

В съответствие с текущата ситуация беше решено да се разработи и внедри система за наблюдение на мрежата, която да реши всички горепосочени проблеми, които, обобщени, могат да бъдат изразени по следния начин:

Необходимо е да се разработи и внедри система за мониторинг, която позволява наблюдение както на комутатори, рутери от различни производители, така и сървъри на различни платформи. Фокус върху използването на отворени протоколи и системи, с максимално използване на готови разработки от фонда за свободен софтуер, което от икономическа гледна точка свежда до нула разходите за лицензиране на крайната система.

Системата трябва да отговаря на следните икономически изисквания:

· минимални изисквания за хардуерни ресурси (води до намаляване на разходите за хардуерната част на проекта);

· кодове с отворен код на всички компоненти на комплекса (позволява ви независимо да променяте принципа на работа на системата, без да прибягвате до помощта на патентовани разработки на трети страни и намалява разходите за лицензиране на продукти);

· разширяемост и мащабируемост на системата (позволява ви да разширите обхвата на приложение, без да прибягвате до разработки на трети страни и патентовани разработки и намалява разходите за лицензиране на продукти);

· стандартни средства за предоставяне на диагностична информация (ви позволява да намалите разходите за поддръжка на системата);

· наличие на подробна документация за всички използвани софтуерни продукти (дава възможност за бързо обучение на нов служител);

· способност за работа с оборудване от различни производители (дава възможност за използване на един софтуерен продукт). (За пълен списък на оборудването вижте Приложение B).

Общо разработката на проекта отне 112 часа (2 седмици). Изпълнението на този проект ще отнеме 56 часа (1 седмица).

1 Изчисляване на разходите за разработване на проекта

Разходите за разработване на проекта се състоят от:

· разходи за заплати;

· разходи за амортизация на оборудване и програмни продукти;

· разходи за електроенергия;

· режийни разходи.

Разходи за заплати.

При изчисляване на разходите за заплати вземаме предвид, че този проект е разработен от един човек: системен инженер.

Средната пазарна заплата за системен инженер на необходимото ниво в региона е 30 000 рубли.

Нека изчислим цената на 1 час инженерна работа въз основа на следните данни:

· бонус 25%;

· регионален коефициент 15 %;

· фондът работно време през 2010 г. по производствения календар е 1988 часа;

По този начин цената, като се вземе предвид регионалния коефициент, ще бъде:

RF = 30000*1.25*1.15*12/1988 = 260 рубли

При изчисляване на разходите за заплати се вземат предвид удръжките, изплатени от натрупаните заплати, тоест общата стойност на ставката на застрахователната премия ще бъде равна на максималната ставка на UST - 26%, включително:

· фонд Пенсии - 20%;

· FSSR - 2,9%

· ФФОМС - 1,1%;

· ГФОМС - 2%;

· Задължително социално осигуряване срещу злополука - 0,2%.

Общите удръжки ще бъдат:

CO = RF * 0,262 = 260 * 0,262 = 68 rub.

Като вземем предвид работното време на инженера (112 часа за разработка и 56 часа за внедряване), изчисляваме разходите за заплати:

Заплата = (112 + 56) * (RF + CO) = 168 * 328 = 55104 rub.

Разходи за амортизация на оборудване и програмни продукти.

Персонален компютър и сървър AQUARIUS SERVER T40 S41 бяха използвани като основно оборудване на етапа на разработка на мрежовия проект. Цената на компютър в момента е приблизително 17 000 рубли, докато сървърът е 30 000 рубли.

По този начин цената на еднократните инвестиции в оборудване ще бъде:

RBA = 47 000 рубли

По време на живота на компютъра и сървъра е разрешена тяхната модернизация, този видразходите също се вземат предвид при изчислението. Заделяме 50% от RV за модернизация:

РМА = РВ * 0,5 = 23 500 рубли

Компютърът е използван на следните етапи:

· търсене на литература;

· търсене на решения за проектиране на система за наблюдение на мрежата;

· развитие на структури и подсистеми;

· проектиране на система за наблюдение на мрежата;

· изпълнение на документ.

Сървърът е използван при внедряване на системата и директна работа със системата.

Софтуерните продукти, използвани в разработката, са получени под безплатни лицензи, което означава, че тяхната цена е нулева и не е необходимо тяхното обезценяване.

По този начин общите разходи за оборудване, като се вземат предвид амортизациите, ще бъдат:

OZA = RVA + RMA = 47 000 + 23 500 = 70 500 рубли

Приема се, че полезният живот е 2 години. Цената на един час работа е (при 22 работни дни в месеца и при 8-часов работен ден):

SOCHR = OZA / BP = 70500 / 4224 = 16,69 рубли

По време на разработването и внедряването разходите за амортизационните такси съответно ще бъдат:

SACHRV = SOCR * TRV = 16,69 * 168 = 2803,92 рубли

Разходи за електроенергия.

Разходите за електроенергия се състоят от енергията, консумирана от компютъра, и енергията, изразходвана за осветление. Цена на електроенергия:

SEN = 0,80 rub / kW * h (По споразумение със собственика на помещението)

Pk,s = 200 W - мощност, консумирана от компютър или сървър.

Trk = 168 часа - време за работа на компютъра на етапа на разработка и внедряване на системата.

Trs = 52 часа - време за работа на сървъра на етапа на разработка и внедряване на системата.

По този начин цената на електроенергията на етапа на разработване и изпълнение на проекта ще бъде:

SENP = Rk * Trk * SEN + Rk * Trs * SEN = (200 * 168 * 0,80 + 200 * 52 * 0,80) / 1000 = (26880 + 8320) / 1000 = 35,2 рубли

Работното място, където е извършена тази работа, е оборудвано с лампа от 100 W. Нека изчислим цената на електроенергията, консумирана от осветителното устройство по време на разработването и внедряването на системата:

SENO = 100 * Trk * SEN = (100 * 168 * 0,80) / 1000 = 13,44 рубли

Общите разходи за енергия бяха:

OZEN = SENP + SENO = 35,2 + 13,44 = 48,64 рубли

8.2 Изчисляване на режийните разходи

Тази разходна позиция покрива разходите за друго оборудване и Консумативи, също и непредвидени разходи.

Режийните разходи в бюджета на предприятието възлизат на 400% от начислените заплати:

NR = заплата * 4 = 55104 * 4 = 220416 rub.

По този начин разходите за разработване и изпълнение на проекта бяха:

SRV = ZP + SACHRV + OZEN + NR = 55104 + 2803.92 + 48.64 + 220416 = 278372.56 рубли

3 Ефективност

В резултат на икономически изчисления минималната цена за разработване и внедряване на система за наблюдение на мрежата беше определена на 278 372,56 рубли.

Както се вижда от изчисленията, преобладаващата част от разходите за разходи се падат на материали и оборудване. Това се обяснява с факта, че производителите на основното оборудване са чуждестранни компании и съответно цените за тези продукти са дадени в щатски долари по обменния курс на Централната банка на Русия + 3%. А увеличаването на митата върху вносните продукти също се отразява негативно на цената за крайните клиенти.

За да оправдаем независимото развитие на системата, нека сравним нейната цена с готови решенияприсъства на пазара:

· D-Link D-View - 360 000 рубли

Изпратете добрата си работа в базата знания е лесно. Използвайте формата по-долу

Студенти, докторанти, млади учени, които използват базата от знания в обучението и работата си, ще ви бъдат много благодарни.

Публикувано на http://www.allbest.ru/

РЕЗЮМЕ

Този документ е технически проект за разработване и внедряване на система за наблюдение на мрежата за обществената мрежа за предаване на данни на град Верхнепишминск на Gerkon LLC. Проектът проведе проучване на съществуващите системи за наблюдение на мрежата, анализира текущата ситуация в предприятието и обоснова избора на конкретни компоненти на системата за наблюдение на мрежата.

Документът съдържа описание на проектните решения и спецификациите на оборудването.

Резултатът от проектирането са разработените решения за внедряване и използване на системата:

§ Пълно описание на всички етапи на проектиране, разработка и внедряване на системата;

§ Ръководство на системния администратор, включително описание на потребителския интерфейс на системата.

Този документ представлява цялостни дизайнерски решения и може да се използва за внедряване на системата.

СПИСЪК НА ЛИСТНИ ГРАФИЧНИ ДОКУМЕНТИ

Таблица 1 - Списък на листове графични документи

СПИСЪК НА КОНВЕНЦИИ, СИМВОЛИ И ТЕРМИНИ

Ethernet е стандарт за предаване на данни, издаден от IEEE. Определя как да предавате или получавате данни от обща среда за предаване на данни. Формира долния транспортен слой и се използва от различни протоколи от по-високо ниво. Осигурява скорост на трансфер на данни от 10Mbit/sec.

Fast Ethernet е технология за предаване на данни със скорост 100 Mbit/s, използвайки метода CSMA/CD, като 10Base-T.

FDDI - Fiber Distributed Data Interface - оптичен интерфейс за разпределено предаване на данни - технология за предаване на данни със скорост 100 Mbit/s, използвайки метода token ring.

IEEE - Институт на инженерите по електротехника и електроника (Institute of Electrical and Electronics Engineers) е организация, която разработва и публикува стандарти.

LAN - Local Area Network - локална мрежа, LAN.

MAC адрес - Media Access Control - идентификационен номер на мрежово устройство, обикновено определян от производителя.

RFC - Request for Comments - набор от документи, издадени от организацията IEEE, който включва описание на стандарти, спецификации и др.

TCP/IP - Transmission Control Protocol/ Internet Protocol - протокол за контрол на предаването/Интернет протокол.

LAN - Локална мрежа.

OS - Операционна система.

Софтуер - Софтуер.

СКС - Структурна кабелна система.

СУБД - Система за управление на бази данни.

Тенденция - Дългосрочна статистика, която ви позволява да изградите така наречената тенденция.

Изхвърляне - Зареждане на канал или сегмент.

КОМПЮТЪР - Електронен компютър.

ВЪВЕДЕНИЕ

Информационната инфраструктура на едно модерно предприятие е сложен конгломерат от многомащабни и разнородни мрежи и системи. За да се гарантира безпроблемното им и ефективно функциониране, е необходима платформа за управление в мащаб на предприятието с интегрирани инструменти. Доскоро обаче самата структура на индустрията за управление на мрежата възпрепятстваше създаването на такива системи - „играчите“ на този пазар търсеха лидерство, като пускаха продукти с ограничен обхват, използвайки инструменти и технологии, които не бяха съвместими със системи от други доставчици.

Днес ситуацията се променя към по-добро - появяват се продукти, които претендират да бъдат универсални в управлението на цялото разнообразие от корпоративни информационни ресурси, от настолни системи до мейнфрейми и от локални мрежи до интернет ресурси. В същото време има осъзнаване, че приложенията за управление трябва да бъдат отворени за решения от всички доставчици.

Актуалността на тази работа се дължи на факта, че във връзка с разпространението на персоналните компютри и създаването на автоматизирани работни станции (AWS) на тяхна база се увеличи значението на локалните компютърни мрежи (LAN), чиято диагноза е обект на нашето изследване. Предмет на изследването са основните методи за организиране и провеждане на диагностика на съвременни компютърни мрежи.

"Диагностика на локална мрежа" е процес на (непрекъснат) анализ на състоянието на информационната мрежа. Когато възникне неизправност на мрежовото устройство, фактът на неизправността се записва, определя се нейното местоположение и вид. Изпраща се съобщение за повреда, устройството се изключва и се заменя с резервно.

Мрежовият администратор, който най-често отговаря за извършването на диагностика, трябва да започне да изучава характеристиките на своята мрежа още във фазата на нейното формиране, т. да познава мрежовата схема и подробно описание на софтуерната конфигурация, посочваща всички параметри и интерфейси. За обработката и съхраняването на тази информация са подходящи специални системи за мрежова документация. Използвайки ги, системният администратор ще знае предварително всички възможни „скрити дефекти“ и „тесни места“ на своята система, така че в случай на аварийна ситуация да знае какъв е проблемът с хардуера или софтуера, дали програмата е повредени или грешка е довела до действия на оператора.

Мрежовият администратор трябва да помни, че от гледна точка на потребителите качеството на приложния софтуер в мрежата е решаващо. Всички други критерии, като броя на грешките при предаване на данни, степента на претоварване на мрежовите ресурси, производителността на оборудването и т.н., са второстепенни. „Добра мрежа“ е тази, чиито потребители не забелязват как работи.

Компания

Преддипломният стаж се проведе в компанията Gerkon LLC в отдела за поддръжка като системен администратор. Компанията предлага услуги за достъп до Интернет в градовете Верхняя Пишма и Среднеуралск, използвайки Ethernet технология и комутируеми канали от 1993 г. и е един от първите доставчици на интернет услуги в тези градове. Правилата за предоставяне на услуги се регулират от публичната оферта и правилника.

Научни и производствени задачи на поделението

Отделът за поддръжка решава следния набор от задачи в рамките на дадено предприятие:

§ техническа и технологична организация за осигуряване на достъп до Интернет чрез комутируеми и специализирани канали;

§ техническа и технологична организация на безжичния достъп до Интернет;

§ разпределяне на дисково пространство за съхранение и осигуряване на работата на сайтове (хостинг);

§ поддръжка на пощенски кутии или виртуален пощенски сървър;

§ разполагане на оборудването на клиента в сайта на доставчика (колокация);

§ отдаване под наем на специализирани и виртуални сървъри;

§ архивиране на данни;

§ внедряване и поддръжка на корпоративни мрежи на частни предприятия.

В процеса на дейност и увеличаване на обема на предоставяне на услуги възникна проблемът с проактивното откриване на неизправности и слаби места в мрежовата организация, тоест задачата беше да се приложи решение, което да позволи да се предвиди необходимостта от подмяна или надграждане на мрежови секции преди повредите да засегнат работата на абонатните възли.

1. СИСТЕМИ ЗА МРЕЖОВ МОНИТОРИНГ

Въпреки множеството техники и инструменти за откриване и отстраняване на проблеми в компютърните мрежи, „почвата под краката“ на мрежовите администратори все още е доста разклатена. Компютърните мрежи все повече включват оптични и безжични компоненти, които правят традиционните медни кабелни технологии и инструменти безсмислени. Освен това при скорости над 100 Mbps традиционните диагностични подходи често спират да работят, дори ако предавателната среда е обикновен меден кабел. Въпреки това, може би най-значимата промяна в компютърната мрежова технология, с която администраторите трябваше да се борят, беше неизбежното преминаване от Ethernet мрежи със споделена медия към комутирани мрежи, в които комутираните сегменти често са отделни сървъри или работни станции.

Вярно е, че с настъпването на технологичните трансформации някои стари проблеми се разрешиха от само себе си. Коаксиалният кабел, който винаги е бил по-труден за откриване на електрически повреди от усуканата двойка, се превръща в рядкост в корпоративната среда. Мрежите Token Ring, чийто основен проблем беше тяхната разлика с Ethernet (а не изобщо техническа слабост), постепенно се заменят от комутирани Ethernet мрежи. Протоколите, които генерират многобройни съобщения за грешка на протокола на мрежовия слой, като SNA, DECnet и AppleTalk, се заменят с IP. Самият стек от IP протоколи стана по-стабилен и по-лесен за поддръжка, както е доказано от милиони клиенти и милиарди уеб страници в Интернет. Дори заклетите опоненти на Microsoft трябва да признаят, че свързването на новия Windows клиент към Интернет е много по-лесно и по-надеждно от инсталирането на предишни TCP/IP стекове на трети страни и отделен софтуер за комутируема връзка.

Колкото и много от днешните технологии да затрудняват отстраняването на неизправности и управлението на производителността на мрежата, ситуацията може да бъде още по-трудна, ако ATM технологията стане широко разпространена на ниво компютър. Също така изигра положителна роля, че в края на 90-те години, преди да получат признание, някои други високоскоростни технологии за обмен на данни бяха отхвърлени, включително Token Ring с пропускателна способност от 100 Mbit/s, 100VG-AnyLAN и усъвършенствани мрежи ARCnet. И накрая, много сложният стек от протоколи OSI (който обаче беше легализиран от редица европейски правителства) беше отхвърлен в Съединените щати.

Нека да разгледаме някои текущи проблеми, с които се сблъскват администраторите на фирмени мрежи.

Йерархичната топология на компютърните мрежи с Gigabit Ethernet backbone и специални превключвателни портове от 10 или дори 100 Mbit/s за индивидуални клиентски системи направи възможно увеличаването на максималната пропускателна способност, потенциално достъпна за потребителите, с поне 10-20 пъти. Разбира се, в повечето компютърни мрежи има тесни места на ниво сървър или рутер за достъп, тъй като честотната лента на потребител е значително по-малка от 10 Mbit/s. Поради това замяната на 10 Mbps хъб порт със специален 100 Mbps комутационен порт за крайния възел не винаги води до значително увеличение на скоростта. Въпреки това, ако вземете предвид, че цената на комутаторите наскоро е намаляла и повечето предприятия са инсталирали кабел от категория 5, който поддържа 100 Mbps Ethernet технология, и са инсталирали мрежови карти, способни да работят при скорости от 100 Mbps веднага след рестартиране на системата, това става ясно защо е толкова трудно да се устои на изкушението да се модернизира. В традиционна споделена медийна LAN анализатор на протоколи или монитор може да изследва целия трафик в даден мрежов сегмент.

Ориз. 1.1 - Традиционна локална мрежа със споделена среда за предаване и анализатор на протоколи

Въпреки че предимството на производителността на комутираната мрежа понякога е едва доловимо, възходът на комутираните архитектури има катастрофални последици за традиционните инструменти за диагностика. В силно сегментирана мрежа анализаторите на протоколи могат да видят само едноадресен трафик на единичен порт на превключвателя, за разлика от наследената мрежова топология, където те биха могли да изследват внимателно всеки пакет в домейна на сблъсък. При такива условия традиционните инструменти за мониторинг не могат да събират статистика за всички „диалози“, тъй като всяка „говореща“ двойка крайни точки използва по същество своя собствена мрежа.

Ориз. 1.2 - Комутирана мрежа

В комутирана мрежа анализаторът на протоколи в един момент може да "види" само един сегмент, освен ако комутаторът не е в състояние да дублира няколко порта едновременно.

За да поддържат контрол над силно сегментираните мрежи, производителите на комутатори предлагат различни инструменти за възстановяване на пълната видимост на мрежата, но много предизвикателства остават по пътя. Превключвателите, които се доставят в момента, обикновено поддържат дублиране на портове, при което трафикът от един порт се дублира към неизползван преди това порт, към който е свързан монитор или анализатор.

„Огледалото“ обаче има редица недостатъци. Първо, само един порт е видим в даден момент, така че отстраняването на проблеми, които засягат множество портове, е трудно. Второ, дублирането може да влоши производителността на комутатора. Трето, отказите на физическия слой обикновено не се възпроизвеждат на огледалния порт и понякога дори обозначенията на VLAN се губят. И накрая, в много случаи пълнодуплексните Ethernet връзки не могат да бъдат напълно огледални.

Частично решение за анализиране на агрегираните параметри на трафика е използването на възможностите за наблюдение на mini-RMON агентите, особено след като те са вградени във всеки порт на повечето Ethernet комутатори. Въпреки че mini-RMON агентите не поддържат групата Capture обекти на спецификацията RMON II, които предоставят пълнофункционален анализ на протокола, те все още могат да осигурят представа за използването на ресурсите, нивата на грешки и обема на мултикаст.

Някои от недостатъците на технологията за дублиране на портове могат да бъдат преодолени чрез инсталиране на "пасивни кранове", произведени например от Shomiti. Тези устройства са с предварително инсталирани Y-конектори и ви позволяват да наблюдавате действителния сигнал, а не регенерирания, с помощта на анализатор на протоколи или друго устройство.

Следващият наболял проблем е проблемът с характеристиките на оптиката. Администраторите на компютърни мрежи обикновено използват специализирано диагностично оборудване за оптична мрежа само за отстраняване на проблеми с оптичния кабел. Конвенционалният стандартен SNMP или базиран на CLI софтуер за управление на устройства може да идентифицира проблеми на комутатори и рутери с оптични интерфейси. И само няколко мрежови администратори са изправени пред необходимостта да диагностицират SONET устройства.

Що се отнася до оптичните кабели, има значително по-малко причини за възможни неизправности в тях, отколкото в случая с медния кабел. Оптичните сигнали не причиняват пресичане, което се получава, когато сигнал на единия проводник индуцира сигнал на другия, което е едно от най-големите предизвикателства за диагностичното медно оборудване. Оптичните кабели са имунизирани срещу електромагнитен шум и индуцирани сигнали, така че не е необходимо да бъдат разположени далеч от асансьорни двигатели и флуоресцентни лампи, което означава, че всички тези променливи могат да бъдат елиминирани от диагностичния сценарий.

Силата на сигнала или оптичната мощност в дадена точка наистина е единствената променлива, която трябва да се измерва при отстраняване на проблеми с оптични мрежи. Ако загубата на сигнал може да се определи по целия оптичен канал, тогава почти всеки проблем може да бъде идентифициран. Евтините допълнителни модули за тестери за медни кабели позволяват оптични измервания.

Предприятията, които са разположили голяма оптична инфраструктура и я поддържат сами, може да се наложи да закупят оптичен рефлектометър във времеви домейн (OTDR), който изпълнява същите функции за оптично влакно като рефлектометър във времеви домейн (TDR) за меден кабел. Устройството работи като радар: изпраща импулсни сигнали по кабела и анализира техните отражения, въз основа на които идентифицира повреда в проводника или друга аномалия, след което казва на експерта къде да търси източника на проблема в кабел.

Въпреки че различни доставчици на кабели и конектори са опростили процеса на прекратяване и разклоняване на оптични влакна, той все още изисква известно ниво на специализирани умения и с разумни политики едно предприятие с обширна оптична инфраструктура ще трябва да обучи своите служители. Колкото и добре да е положена кабелната мрежа, винаги съществува възможност за физическа повреда на кабела в резултат на някакъв неочакван инцидент.

Проблеми могат да възникнат и при диагностициране на 802.11b безжични LAN. Самата диагностика е толкова проста, колкото в случая на Ethernet мрежи, базирани на концентратори, тъй като безжичната среда за предаване на информация се споделя между всички собственици на клиентски радиоустройства. Sniffer Technologies първи предложи решение за анализиране на протоколите на такива мрежи с пропускателна способност до 11 Mbps, а впоследствие повечето от водещите производители на анализатори въведоха подобни системи.

За разлика от Ethernet хъб с кабелни връзки, качеството на безжичните клиентски връзки далеч не е стабилно. Микровълновите радиосигнали, използвани във всички локални опции за предаване, са слаби и понякога непредвидими. Дори малки промени в позицията на антената могат сериозно да повлияят на качеството на връзките. Точките за достъп до безжична LAN се доставят с конзола за управление на устройства и това често е по-ефективен диагностичен метод от посещението на безжични клиенти и наблюдението на пропускателна способност и грешки с ръчен анализатор.

Въпреки че проблемите със синхронизирането на данни и инсталирането на устройството, с които се сблъскват потребителите на лични цифрови асистенти (PDA), попадат по-естествено в рамките на отговорностите на екипа за техническа поддръжка, а не в отговорностите на мрежовия администратор, не е трудно да се предвиди, че в не-твърде- в далечното бъдеще много такива устройства ще се превърнат от самостоятелни аксесоари, допълващи компютъра, в пълни мрежови клиенти.

Като цяло, корпоративните оператори на безжични мрежи ще (или трябва) да обезсърчават внедряването на прекалено отворени системи, в които всеки потребител в обхвата на мрежата със съвместима интерфейсна карта има достъп до всеки кадър с данни на системата. Безжичният протокол за сигурност WEP (Wired Equivalent Privacy) осигурява удостоверяване на потребителя, гаранция за цялост и криптиране на данните, но, както обикновено се случва, сложната система за сигурност усложнява анализа на причините за мрежовите проблеми. В защитени мрежи с активиран WEP диагностичните техници трябва да знаят ключовете или паролите, които защитават информационните ресурси и контролират достъпа до системата. При достъп в режим на получаване на всички пакети, анализаторът на протоколи ще може да види всички заглавки на рамката, но информацията, съдържаща се в тях, ще бъде безсмислена без наличието на ключове.

При диагностицирането на тунелирани връзки, които много доставчици наричат ​​виртуални частни мрежи за отдалечен достъп, срещаните проблеми са подобни на тези, срещани при анализиране на криптирани безжични мрежи. Ако трафикът не преминава през тунелирания канал, причината за проблема не е лесна за определяне. Това може да е грешка при удостоверяване, повреда в една от крайните точки или задръстване в публичната интернет зона. Опитът да се използва анализатор на протоколи за идентифициране на грешки на високо ниво в тунелиран трафик би бил загуба на усилия, тъй като съдържанието на данните, както и заглавките на приложението, транспорта и мрежовия слой са криптирани. Като цяло мерките, предприети за подобряване на сигурността на корпоративните мрежи, обикновено затрудняват идентифицирането на грешки и проблеми с производителността. Защитните стени, прокси сървърите и системите за откриване на проникване могат допълнително да усложнят отстраняването на проблеми.

Следователно проблемът с диагностицирането на компютърни мрежи е актуален и в крайна сметка диагностицирането на неизправности е задача на управлението. За повечето критични корпоративни системи дългите усилия за възстановяване не са опция, така че единственото решение е да се използват резервни устройства и процеси, които могат да поемат необходимите функции веднага след възникване на повреди. В някои предприятия мрежите винаги имат допълнителен резервен компонент в случай, че основният компонент се повреди, т.е. n x 2 компонента, където n е броят на основните компоненти, необходими за осигуряване на приемлива производителност. Ако средното време за ремонт (MTTR) е достатъчно високо, тогава може да е необходимо дори повече резервиране. Факт е, че времето за ремонт не е лесно да се предвиди и значителните разходи по време на непредсказуем период на възстановяване са знак за лошо управление.

За по-малко критични системи резервирането може да не е икономически осъществимо, в който случай може да си струва да инвестирате в най-ефективните инструменти (и обучение на персонала), за да ускорите отстраняването на неизправности във вашето предприятие. В допълнение, поддръжката за определени системи може да бъде възложена на външни изпълнители или чрез сключване на договор за тях вътрешно, чрез използване на външни центрове за данни или чрез използване на доставчици на услуги за приложения (ASP) или доставчици на услуги за управление. В допълнение към разходите, най-важният фактор, който влияе върху решението за използване на услуги на трети страни, е нивото на компетентност на вътрешния персонал. Мрежовите администратори трябва да решат дали определена функция е толкова тясно свързана със специфичните цели на предприятието, че не може да се очаква външен специалист да свърши по-добра работа, отколкото може да бъде свършена от собствените служители на компанията.

Почти веднага след разгръщането на първите корпоративни мрежи, чиято надеждност остави много да се желае, производителите и разработчиците представиха концепцията за „самовъзстановяващи се мрежи“. Съвременните мрежи със сигурност са по-надеждни, отколкото през 90-те години, но не защото проблемите са се самокоригирали. Отстраняването на софтуерни и хардуерни повреди в съвременните мрежи все още изисква човешка намеса и не се очакват фундаментални промени в това състояние на нещата в близко бъдеще. Техниките и инструментите за диагностика са в рамките на настоящата практика и технология, но все още не са достигнали ниво, което може значително да спести време на мрежовите администратори, докато се борят с мрежови проблеми и затруднения в производителността.

1 .1 Диагностичен софтуер

Сред софтуерните инструменти за диагностика на компютърни мрежи можем да подчертаем специални системи за управление на мрежата (системи за управление на мрежата) - централизирани софтуерни системи, които събират данни за състоянието на мрежовите възли и комуникационните устройства, както и данни за трафика, циркулиращ в мрежата. Тези системи не само наблюдават и анализират мрежата, но и извършват действия по управление на мрежата в автоматичен или полуавтоматичен режим – активиране и дезактивиране на портове на устройства, промяна на параметрите на моста, адресни таблици на мостове, комутатори и рутери и др. Примери за системи за управление включват популярните системи HPOpenView, SunNetManager, IBMNetView.

Инструментите за управление на системата изпълняват функции, подобни на тези на системите за управление, но във връзка с комуникационно оборудване. В същото време някои функции на тези два типа системи за управление могат да бъдат дублирани; например инструментите за управление на системата могат да извършват прост анализ на мрежовия трафик.

Експертни системи. Този тип система акумулира човешки знания за идентифициране на причините за ненормална работа на мрежите и възможните начини за привеждане на мрежата в работно състояние. Експертните системи често се реализират като отделни подсистеми на различни инструменти за наблюдение и анализ на мрежата: системи за управление на мрежата, анализатори на протоколи, мрежови анализатори. Най-простата версия на експертна система е контекстно-чувствителна помощна система. По-сложните експертни системи са така наречените бази от знания, които имат елементи на изкуствен интелект. Пример за такава система е експертната система, вградена в системата за управление Spectrum на Cabletron.

1.1.1 Анализатори на протоколи

Когато се проектира нова или надгражда стара мрежа, често има нужда от количествено измерване на определени мрежови характеристики, като например интензивността на потоците от данни по мрежовите комуникационни линии, закъсненията, които възникват на различни етапи от обработката на пакети, времето за отговор на заявки на един тип или друг, честотата на възникване на определени събития и други характеристики.

За тези цели могат да се използват различни инструменти и преди всичко инструменти за наблюдение в системите за управление на мрежата, които вече бяха обсъдени по-рано. Някои мрежови измервания могат да се извършват и със софтуерни измервателни уреди, вградени в операционната система; пример за това е компонентът Windows Performance Monitor OS. Дори съвременните кабелни тестери са способни да улавят пакети и да анализират тяхното съдържание.

Но най-модерният инструмент за изследване на мрежата е анализатор на протоколи. Процесът на анализ на протокола включва улавяне на пакети, циркулиращи в мрежа, които прилагат конкретен мрежов протокол, и изучаване на съдържанието на тези пакети. Въз основа на резултатите от анализа е възможно да се направят разумни и балансирани промени във всеки мрежов компонент, да се оптимизира неговата производителност и да се отстранят проблеми. Очевидно, за да се направят каквито и да било заключения относно въздействието на промяната върху мрежата, е необходимо да се анализират протоколите както преди, така и след извършването на промяната.

Анализаторът на протоколи е независимо специализирано устройство или персонален компютър, обикновено преносим, ​​от клас Htebook, оборудван със специална мрежова карта и подходящ софтуер. Използваната мрежова карта и софтуер трябва да отговарят на мрежовата топология (пръстен, шина, звезда). Анализаторът се свързва към мрежата по същия начин като обикновен възел. Разликата е, че анализаторът може да получи всички пакети данни, предадени по мрежата, докато обикновената станция може да получи само тези, адресирани до нея. Софтуерът на анализатора се състои от ядро, което поддържа работата на мрежовия адаптер и декодира получените данни, и допълнителен програмен код, в зависимост от вида на топологията на изследваната мрежа. Освен това се доставят редица специфични за протокола процедури за декодиране, като IPX. Някои анализатори могат също да включват експертна система, която може да предостави на потребителя препоръки за това какви експерименти трябва да се извършат в дадена ситуация, какво могат да означават определени резултати от измерване и как да се елиминират определени видове мрежови повреди.

Въпреки относителното разнообразие от анализатори на протоколи на пазара, има някои характеристики, които са общи за всички тях в една или друга степен:

Потребителски интерфейс. Повечето анализатори имат разработен удобен за потребителя интерфейс, обикновено базиран на Windows или Motif. Този интерфейс позволява на потребителя да: показва резултатите от анализа на интензивността на трафика; получавате моментална и средна статистическа оценка на производителността на мрежата; задайте определени събития и критични ситуации, за да проследите тяхното възникване; декодиране на протоколи от различни нива и представяне на съдържанието на пакетите в разбираема форма.

Буфер за улавяне. Буферите на различните анализатори се различават по размер. Буферът може да се намира на инсталирана мрежова карта или за него може да бъде отделено място в RAM на някой от компютрите в мрежата. Ако буферът се намира на мрежовата карта, тогава той се управлява хардуерно и поради това скоростта на въвеждане се увеличава. Това обаче оскъпява анализатора. Ако изпълнението на процедурата за улавяне е недостатъчно, част от информацията ще бъде загубена и анализът ще бъде невъзможен. Размерът на буфера определя възможностите за анализ на повече или по-малко представителни проби от уловените данни. Но колкото и голям да е буферът за улавяне, рано или късно той ще се напълни. В този случай или прихващането спира, или пълненето започва от началото на буфера.

Филтри. Филтрите ви позволяват да контролирате процеса на събиране на данни и по този начин спестявате буферно пространство. В зависимост от стойността на определени пакетни полета, зададени като условие за филтър, пакетът или се игнорира, или се записва в буфера за улавяне. Използването на филтри значително ускорява и опростява анализа, тъй като елиминира преглеждането на ненужни в момента пакети.

Превключвателите са определени условия, определени от оператора за стартиране и спиране на процеса на прихващане на данни от мрежата. Такива условия могат да включват изпълнение на ръчни команди за стартиране и спиране на процеса на улавяне, час от деня, продължителност на процеса на улавяне и появата на определени стойности в кадри с данни. Превключвателите могат да се използват заедно с филтри, което позволява по-подробен и нюансиран анализ, както и по-продуктивно използване на ограниченото буферно пространство за улавяне.

Търсене. Някои анализатори на протоколи ви позволяват да автоматизирате преглеждането на информация в буфера и да намирате данни в него въз основа на определени критерии. Докато филтрите проверяват входния поток, за да видят дали отговаря на условията на филтъра, функциите за търсене се прилагат към данните, които вече са натрупани в буфера.

Методологията на анализа може да бъде представена в следните шест етапа:

1. Прихващане на данни.

2. Преглед на заснетите данни.

3. Анализ на данни.

4. Търсене на грешки. (Повечето анализатори улесняват тази работа, като откриват типове грешки и идентифицират станцията, от която идва пакетът за грешка.)

5. Изследване на ефективността. Изчислява се степента на използване на честотната лента на мрежата или средното време за отговор на заявка.

6. Детайлно проучване на отделни участъци от мрежата. Съдържанието на този етап се уточнява с напредването на анализа.

Обикновено процесът на анализиране на протоколите отнема сравнително малко време - 1-2 работни дни.

Повечето съвременни анализатори ви позволяват да анализирате няколко глобални мрежови протокола наведнъж, като X.25, PPP, SLIP, SDLC/SNA, frame relay, SMDS, ISDN, протоколи за мост/рутер (3Com, Cisco, Bay Networks и други). Такива анализатори ви позволяват да измервате различни параметри на протоколи, да анализирате мрежов трафик, преобразуване между протоколи на локална и глобална мрежа, забавяне на рутери по време на тези преобразувания и т.н. По-усъвършенстваните инструменти предоставят възможност за симулиране и декодиране на глобални мрежови протоколи, „стрес“ тестове, и измерване на максимална пропускателна способност, тестване на качеството на предоставяните услуги. В името на гъвкавостта почти всички WAN анализатори на протоколи прилагат функции за тестване за LAN и всички основни интерфейси. Някои устройства могат да анализират телефонни протоколи. И най-модерните модели могат да декодират и представят всичките седем OSI слоя по удобен начин. Появата на ATM накара производителите да оборудват своите анализатори с инструменти за тестване на тези мрежи. Такива устройства могат да провеждат пълно тестване на E-1/E-3 ATM мрежи с поддръжка за мониторинг и симулация. Наборът от сервизни функции на анализатора е много важен. Някои от тях, като възможността за дистанционно управление на устройството, са просто незаменими.

По този начин съвременните WAN/LAN/DTM анализатори на протоколи могат да откриват грешки в конфигурацията на рутери и мостове; задайте вида на трафика, изпратен през глобалната мрежа; определяне на използвания скоростен диапазон, оптимизиране на съотношението между пропускателна способност и брой канали; локализиране на източника на неправилен трафик; Извършване на тестване на сериен интерфейс и пълно тестване на ATM; извършва пълен мониторинг и декодиране на основните протоколи на всеки канал; анализира статистика в реално време, включително анализ на трафика на локалната мрежа през глобалните мрежи.

1.1.2 Протоколи за наблюдение

SNMP протокол

SNMP (Simple Network Management Protocol) е протокол за управление на комуникационна мрежа, базиран на TCP/IP архитектурата.

Въз основа на концепцията TMN през 1980-1990 г. Различни органи за стандартизация са разработили редица протоколи за управление на мрежи за данни с различен обхват на изпълнение на функциите на TMN. Един тип такъв протокол за управление е SNMP. Протоколът SNMP е разработен за тестване на функционирането на мрежови рутери и мостове. Впоследствие обхватът на протокола обхваща и други мрежови устройства, като хъбове, шлюзове, терминални сървъри, сървъри на LAN Manager, машини, работещи под Windows NT и др. В допълнение, протоколът позволява възможността за извършване на промени във функционирането на тези устройства.

Тази технология е предназначена да осигури управление и контрол върху устройства и приложения в комуникационна мрежа чрез обмен на контролна информация между агенти, разположени на мрежови устройства, и мениджъри, разположени на контролни станции. SNMP дефинира мрежа като колекция от станции за управление на мрежата и мрежови елементи (хостове, шлюзове и рутери, терминални сървъри), които заедно осигуряват административни комуникации между станции за управление на мрежата и мрежови агенти.

При използване на SNMP има управлявани и контролни системи. Управляваната система включва компонент, наречен агент, който изпраща отчети до управляващата система. По същество SNMP агентите предават информация за управление на системите за управление като променливи (като „свободна памет“, „име на системата“, „брой изпълнявани процеси“).

Агентът в протокола SNMP е обработващ елемент, който предоставя на мениджърите, разположени в мрежови контролни станции, достъп до стойностите на MIB променливите и по този начин им позволява да изпълняват функции за управление и наблюдение на устройството.

Софтуерният агент е резидентна програма, която изпълнява функции за управление и също така събира статистически данни за прехвърлянето им в информационната база на мрежово устройство.

Хардуерен агент е вграден хардуер (с процесор и памет), в който се съхраняват софтуерни агенти.

Променливите, достъпни чрез SNMP, са организирани в йерархия. Тези йерархии и други метаданни (като тип променлива и описание) се описват от информационни бази за управление (MIB).

Днес има няколко стандарта за бази данни с управленска информация. Основните са стандартите MIB-I и MIB-II, както и версията на базата данни за дистанционно управление RMON MIB. Освен това има стандарти за MIB за специфични устройства от конкретен тип (например MIB за хъбове или MIB за модеми), както и собствени MIB за специфични производители на оборудване.

Оригиналната MIB-I спецификация дефинира само операции за четене на стойности на променливи. Операциите за промяна или задаване на стойности на обекти са част от спецификациите на MIB-II.

Версия MIB-I (RFC 1156) дефинира до 114 обекта, които са разделени на 8 групи:

* Система - общи данни за устройството (например ID на доставчика, време на последна инициализация на системата).

* Интерфейси - описва параметрите на мрежовите интерфейси на устройството (например техния брой, видове, скорости на обмен, максимален размер на пакета).

* AddressTranslationTable - описва съответствието между мрежови и физически адреси (например чрез ARP протокола).

* InternetProtocol - данни, свързани с IP протокола (адреси на IP шлюзове, хостове, статистика за IP пакети).

* ICMP - данни, свързани с ICMP протокола за обмен на контролни съобщения.

* TCP - данни, свързани с TCP протокола (например за TCP връзки).

* UDP - данни, свързани с UDP протокола (брой предадени, получени и грешни UPD дейтаграми).

* EGP - данни, свързани с протокола за обмен на информация за маршрутизиране ExteriorGatewayProtocol, използван в Интернет (броят съобщения, получени с грешки и без грешки).

От този списък с групи променливи става ясно, че стандартът MIB-I е разработен със строг фокус върху управлението на рутери, които поддържат TCP/IP стекови протоколи.

Във версия MIB-II (RFC 1213), приета през 1992 г., наборът от стандартни обекти беше значително разширен (до 185), а броят на групите се увеличи до 10.

RMON агенти

Най-новото допълнение към функционалността на SNMP е спецификацията RMON, която позволява дистанционно взаимодействие с MIB.

Стандартът RMON датира от ноември 1991 г., когато Internet Engineering Task Force пусна RFC 1271, „Информационна база за управление на отдалечено наблюдение на мрежата“. Този документ описва RMON за Ethernet мрежи.

RMON е протокол за мониторинг на компютърна мрежа, разширение на SNMP, който, подобно на SNMP, се основава на събирането и анализа на информация за естеството на информацията, предавана по мрежата. Както и при SNMP, информацията се събира от хардуерни и софтуерни агенти, данните от които се изпращат до компютъра, където е инсталирано приложението за управление на мрежата. Разликата между RMON и неговия предшественик се състои преди всичко в естеството на събраната информация - ако в SNMP тази информация характеризира само събития, случващи се на устройството, където е инсталиран агентът, тогава RMON изисква получените данни да характеризират трафика между мрежови устройства.

Преди RMON SNMP не можеше да се използва дистанционно; позволяваше само локално управление на устройства. RMON MIB има подобрен набор от свойства за отдалечено управление, тъй като съдържа обобщена информация за устройството, което не изисква големи количества информация да се предават по мрежата. Обектите RMON MIB включват допълнителни броячи на грешки в пакети, по-гъвкави графични тенденции и статистически анализ, по-мощни инструменти за филтриране за улавяне и анализиране на отделни пакети и по-сложни условия за предупреждение. RMON MIB агентите са по-интелигентни от MIB-I или MIB-II агентите и изпълняват голяма част от работата по обработка на информацията за устройството, която преди се извършваше от мениджърите. Тези агенти могат да бъдат разположени в различни комуникационни устройства и могат също така да бъдат внедрени като отделни софтуерни модули, работещи на универсални компютри и лаптопи (LANalyzerHvell е пример).

Интелигентността на RMON агентите им позволява да извършват прости действия за диагностициране на неизправности и предупреждават за възможни повреди - например в рамките на технологията RMON можете да събирате данни за нормалното функциониране на мрежата (т.е. да извършвате така нареченото базово ниво ), и след това задайте предупредителни сигнали, когато режимът на работа на мрежата ще се отклони от базовата линия - това може да означава, по-специално, че оборудването не работи напълно. Чрез комбиниране на информация, получена от RMON агенти, приложението за управление може да помогне на мрежов администратор (намиращ се например на хиляди километри от мрежовия сегмент, който се анализира) да локализира проблема и да разработи оптимален план за действие за разрешаването му.

Информацията за RMON се събира от хардуерни и софтуерни сонди, свързани директно към мрежата. За да изпълни задачата за събиране и първичен анализ на данни, сондата трябва да има достатъчно изчислителни ресурси и RAM. В момента на пазара има три вида сонди: интегрирани, компютърно базирани и самостоятелни. Един продукт се счита за съвместим с RMON, ако прилага поне една група RMON. Разбира се, колкото повече RMON групи данни са внедрени в даден продукт, толкова по-скъп е, от една страна, и от друга, толкова по-пълна информация за работата на мрежата предоставя.

Вградените сонди са разширителни модули за мрежови устройства. Такива модули се произвеждат от много производители, по-специално от такива големи компании като 3Com, Cabletron, Bay Networks и Cisco. (Между другото, 3Com и Bay Networks наскоро придобиха Axon и ARMON, признати лидери в разработването и производството на инструменти за управление на RMON. Такъв интерес към тази технология от страна на големите производители на мрежово оборудване още веднъж показва колко необходимо е дистанционното наблюдение за потребителите.) Решението за интегриране на RMON модули в хъбове изглежда естествено, защото от наблюдението на тези устройства може да се добие представа за работата на сегмента. Предимството на такива сонди е очевидно: те ви позволяват да получите информация за всички основни групи RMON данни на сравнително ниска цена. Недостатъкът, на първо място, е, че производителността не е много висока, което се проявява по-специално във факта, че вградените сонди често не поддържат всички групи данни RMON. Неотдавна 3Com обяви намерението си да пусне поддържащи RMON драйвери за мрежови адаптери Etherlink III и Fast Ethernet. В резултат на това ще бъде възможно да се събират и анализират RMON данни директно от работни станции в мрежата.

Компютърно базираните сонди са просто компютри, свързани към мрежа с инсталиран на тях софтуерен агент RMON. Тези сонди (като Cornerstone Agent 2.5 на Network General) имат по-висока производителност от вградените сонди и обикновено поддържат всички RMON групи данни. Те са по-скъпи от вградените сонди, но много по-евтини от самостоятелните сонди. Освен това компютърно базираните сонди са доста големи, което понякога може да ограничи техните приложения.

Автономните сонди предлагат най-висока производителност; Както е лесно да се разбере, това са в същото време най-скъпите продукти от всички описани. Обикновено самостоятелната сонда е процесор (клас i486 или RISC процесор), оборудван с достатъчно RAM и мрежов адаптер. Лидерите в този пазарен сектор са Frontier и Hewlett-Packard. Сондите от този тип са малки по размер и много мобилни - много лесно се свързват и изключват от мрежата. При решаването на проблема с управлението на мрежа от глобален мащаб това, разбира се, не е много важно свойство, но ако инструментите RMON се използват за анализ на работата на средно голяма корпоративна мрежа, тогава (предвид високата цена на устройствата ) мобилността на сондите може да играе много положителна роля.

Обектът RMON е номериран 16 в набора от обекти MIB, а самият обект RMON, както е дефиниран в RFC 1271, се състои от десет групи данни.

* Статистика - текущи натрупани статистически данни за характеристики на пакети, брой колизии и др.

* История - статистически данни, записвани на определени интервали за последващ анализ на тенденциите в техните промени.

* Аларми - прагови стойности на статистически показатели, при превишаване на които агентът RMON изпраща съобщение до мениджъра. Позволява на потребителя да дефинира редица прагови нива (тези прагове могат да се отнасят за различни неща - всеки параметър от групата статистики, амплитудата или скоростта на промяната му и много други), при превишаването на които се генерира аларма. Потребителят може също да определи при какви условия превишаването на праговата стойност трябва да бъде придружено от алармен сигнал - това ще избегне генерирането на сигнал „за нищо“, което е лошо, първо, защото никой не обръща внимание на постоянно горяща червена светлина и второ, защото предаването на ненужни аларми по мрежата води до ненужно натоварване на комуникационните линии. Алармата обикновено се изпраща до група събития, където се определя какво да се прави с нея по-нататък.

* Хост - информация за мрежовите хостове, включително техните MAC адреси..

* HostTopN - таблица на най-натоварените хостове в мрежата. Таблицата с N най-добри хостове (HostTopN) съдържа списък с най-добрите N хостове, които имат максималната стойност на даден статистически параметър за даден интервал. Например, можете да поискате списък с 10 хоста, които са имали най-много грешки през последните 24 часа. Този списък ще бъде съставен от самия агент, а приложението за управление ще получи само адресите на тези хостове и стойностите на съответните статистически параметри. Ясно е до каква степен този подход пести мрежови ресурси

* TrafficMatrix - статистика за интензивността на трафика между всяка двойка мрежови хостове, организирана под формата на матрица. Редовете на тази матрица са номерирани в съответствие с MAC адресите на станциите източник на съобщението, а колоните са номерирани в съответствие с адресите на станциите получатели. Матричните елементи характеризират интензивността на трафика между съответните станции и броя на грешките. Анализирайки такава матрица, потребителят може лесно да разбере кои двойки станции генерират най-интензивен трафик. Тази матрица отново се генерира от самия агент, така че няма нужда да се прехвърлят големи количества данни към централния компютър, отговорен за управлението на мрежата.

* Филтър - условия за филтриране на пакети. Критериите, по които се филтрират пакетите, могат да бъдат много разнообразни - например можете да изисквате всички пакети, чиято дължина е по-малка от определена зададена стойност, да бъдат филтрирани като грешни. Можем да кажем, че инсталирането на филтър съответства на организирането на канал за предаване на пакет. Накъде води този канал се определя от потребителя. Например, всички грешни пакети могат да бъдат прихванати и изпратени до подходящия буфер. В допълнение, появата на пакет, който отговаря на инсталирания филтър, може да се счита за събитие, на което системата трябва да реагира по предварително определен начин.

* PacketCapture - условия за прихващане на пакети. Групата за улавяне на пакети съдържа буфери за улавяне, към които се изпращат пакети, чиито атрибути отговарят на условията, посочени във филтърната група. В този случай не може да бъде уловен целият пакет, а да речем само първите няколко десетки байта от пакета. Съдържанието на буферите за улавяне може впоследствие да бъде анализирано с помощта на различни софтуерни инструменти, разкривайки редица много полезни характеристики на мрежата. Чрез възстановяване на филтрите за определени характеристики е възможно да се характеризират различни параметри на работата на мрежата.

* Събитие - условия за регистриране и генериране на събития. Групата събития определя кога трябва да бъде изпратена аларма към приложението за управление, кога да се прихванат пакети и като цяло как да се реагира на определени събития, възникващи в мрежата, например, когато праговите стойности, ​​посочени в групата аларми, са превишено: дали да зададете уведомяване на контролното приложение, или просто трябва да регистрирате това събитие и да продължите да работите. Събитията може да не са свързани със задействане на аларми - например изпращането на пакет към буфера за улавяне също е събитие.

Тези групи са номерирани по ред, така че например групата Hosts има числово име 1.3.6.1.2.1.16.4.

Десетата група се състои от специални обекти на протокола TokenRing.

Общо стандартът RMON MIB дефинира около 200 обекта в 10 групи, документирани в два документа - RFC 1271 за Ethernet мрежи и RFC 1513 за TokenRing мрежи.

Отличителна черта на стандарта RMON MIB е неговата независимост от протокола на мрежовия слой (за разлика от стандартите MIB-I и MIB-II, които са фокусирани върху TCP/IP протоколи). Поради това е удобно да се използва в хетерогенни среди, използвайки различни протоколи на мрежовия слой.

1 .2 Популярни системи за управление на мрежата

Система за управление на мрежата - хардуер и/или софтуер за наблюдение и управление на мрежови възли. Софтуерът на системата за управление на мрежата се състои от агенти, които се намират на мрежови устройства и предават информация към платформата за управление на мрежата. Методът за обмен на информация между управляващите приложения и агентите на устройствата се определя от протоколи.

Системите за управление на мрежата трябва да притежават редица качества:

* истинско разпределение в съответствие с концепцията клиент/сървър,

* скалируемост,

* отвореност, която ви позволява да се справите с разнородно оборудване - от настолни компютри до мейнфрейми.

Първите две свойства са тясно свързани. Добра мащабируемост се постига благодарение на разпределението на системата за управление. Разпределението означава, че системата може да включва няколко сървъра и клиенти. Сървърите (от мениджъри) събират данни за текущото състояние на мрежата от агенти (SNMP, CMIP или RMON), вградени в мрежовото оборудване и ги натрупват в своята база данни. Клиентите са графични конзоли, управлявани от мрежови администратори. Клиентският софтуер на системата за управление получава заявки за извършване на всякакви действия от администратора (например изграждане на подробна карта на част от мрежата) и се свързва със сървъра за необходимата информация. Ако сървърът има необходимата информация, той незабавно я предава на клиента; ако не, тогава се опитва да я събере от агентите.

Ранните версии на системите за управление комбинираха всички функции в един компютър, който се управляваше от администратор. За малки мрежи или мрежи с малко управлявано оборудване тази структура се оказва доста задоволителна, но с голямо количество управлявано оборудване единственият компютър, към който тече информация от всички мрежови устройства, се превръща в пречка. И мрежата не може да се справи с големия поток от данни, а самият компютър няма време да ги обработи. В допълнение, голяма мрежа обикновено се управлява от повече от един администратор, следователно, в допълнение към няколко сървъра, една голяма мрежа трябва да има няколко конзоли, на които работят мрежовите администратори, и всяка конзола трябва да предоставя специфична информация, която отговаря на текущите нужди на конкретен администратор.

Подобни документи

Разработване на структурата на локалната компютърна мрежа на ДОУ СПО "ВПТ". Обосновка на топологията, избор на хардуер за комутация и сегментация. Инсталиране и конфигуриране на мрежови протоколи и услуги. Система за наблюдение на мрежови възли и мрежов трафик.

дисертация, добавена на 25.10.2013 г


Видове мрежови кабели за локална мрежа. Характеристики на инсталиране на безжична Wi-Fi връзка. Изчисляване на трудоемкостта на работата за създаване на LAN, разходите за нейното разработване и инсталиране. Очаквана печалба от продажбата на LAN, капиталови разходи на купувача.

курсова работа, добавена на 27.12.2010 г


Анализ на административен софтуер за локална мрежа. Структура на мрежовите операционни системи. Планиране и мрежова архитектура на локална мрежа. Използване на мрежови ресурси на примера на предприятие, предоставящо услуги на доставчик на интернет услуги.

тест, добавен на 15.12.2010 г


Анализ и практическо прилагане на използването на мрежова администрация и мониторинг в предприятие. Процесът на създаване на мрежова карта в програмата LANState. Мрежови програми за системни администратори, програми за наблюдение на мрежата. Описание на локалната компютърна мрежа.

курсова работа, добавена на 15.02.2017 г


Класификация на локалната мрежа. Видове топологии на локални мрежи. Модел на взаимодействие между OSI системи. Мрежови устройстваи средства за комуникация. Видове мрежови кабели. Конфигуриране на сървърни компютри, оборудване за работни станции.

курсова работа, добавена на 05.01.2013 г


Топология и принципи на администриране кабелна мрежа, избор на метод за свързване на мрежово оборудване. Проектиране на локална компютърна мрежа. Оценка на разходите за внедряване на структурна кабелна система и система за непрекъсваемо електрозахранване.

дисертация, добавена на 28.10.2013 г


Функционална схемалокална мрежа. Планиране на мрежова структура и топология. IP адресиране и TCP/IP протокол. Настройки мрежов принтери антивирусната система NOD32. Технология за полагане на кабелна система. Технология за създаване на пач кабел.

курсова работа, добавена на 08.08.2015 г


Методи за класифициране на мрежи. Разработване и описание на структурата на локална компютърна мрежа, разположена в пететажна сграда. Техническа информация, йерархична звездна топология. Клиентски хардуер. Инсталиране и конфигуриране на сървър.

курсова работа, добавена на 27.07.2011 г


Избор на пасивно мрежово оборудване. Обосновка на необходимостта от модернизиране на локалната компютърна мрежа на предприятието. Избор на операционна система за работни станции и сървъри. Сравнителни характеристики на D-Link комутатори. Диаграми на локална мрежа.

курсова работа, добавена на 10.10.2015 г


Концепцията и предназначението на локалната мрежа, концепцията за нейното изграждане, избор на топология. Разработване на конфигурация и изчисляване на мрежовите характеристики на LAN на Don Terminal LLC: технически и софтуерни компоненти, цена; Информационна сигурност.