27.06.2011 Нејт МекАлмонд

Избрав три кандидати: WhatsUp Gold Premium од Ipswitch, OpManager Professional од ManageEngine и ipMonitor од SolarWinds. Секој од овие мрежни скенери чини помалку од 3.000 долари (за 100 уреди) и секој доаѓа со пробен период во кој можете бесплатно да го тестирате вашиот производ

Работам за компанија со средна големина и го користиме истиот систем за следење на мрежата околу седум години. На нашите администратори им дава основни информации за достапноста на серверите и услугите, а исто така испраќа СМС текстуални пораки до нашите мобилни телефони во случај на проблеми. Дојдов до заклучок дека е неопходно да се надополни системот или барем да се додаде ефективна алатка која може да обезбеди подобри перформанси и да обезбеди детални информации за здравјето на терминалните сервери, Exchange и SQL системите хостирани на вашата мрежа. . Ајде да ги споредиме нашите кандидати.

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

За да се подготвите за тестирање, првиот чекор беше да се овозможи услугата SNMP на сите уреди, вклучувајќи ги и серверите на Windows. Со менување на поставките за услугата SNMP, поставив пристап само за читање до сите уреди што треба да бидат опфатени со процесот на следење. На системите Windows Server 2003/2000, услугата SNMP се инсталира со помош на волшебникот за компоненти на Windows лоциран во панелот Додај/отстрани програми, а на системите Windows Server 2008, компонентите SNMP се додаваат со помош на волшебникот за Управувач со сервери. По завршувањето на волшебникот, треба да го стартувате додатокот за услуги, кој се наоѓа во папката Контролен панел и да ја конфигурирате услугата 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 уреди. Користејќи ги стандардните поставки за скенирање, тестираните системи успешно ги идентификуваа типовите на уреди и исто така обезбедија детални информации за статусот на уредите. Сите три системи содржат сензори за клучните карактеристики на изведбата на уредите и серверите, како што се: оптоварување на процесорот, употреба на меморија, користење/полност на дискот, загуба/латентност на пакети, статус на размена, Lotus, Active Directory и сите услуги на 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, тие точно се совпаѓаа за секое јадро. Исто така, информациите за користењето на хард дискот беа правилно пријавени до сите релевантни апликации за работниот простор.

Системот WhatsUp Gold има вградена библиотека со сензори која ви овозможува да креирате нови сензори врз основа на постоечките. На големите организации оваа функција може да им биде корисна бидејќи им овозможува да креираат единечни групи сензори за следење на различни типови уреди - најефикасен начин за конфигурирање на сензори за група уреди.

WhatsUp Gold нема сензори за поединечни уреди (со исклучок на сензорот за напојување APC UPS), за разлика од пакетот OpManager, кој користи сопствени сензори за уредите Dell, HP и IBM, но дозволува создавање сензори Active Script . Овој тип ви овозможува да развивате сопствени процеси на следење користејќи ги програмските јазици VBScript и JScript. Онлајн центар за поддршка е посветен на сензорите за Active Script, каде што корисниците на WhatsUp Gold можат да примаат и преземаат готови скрипти.

Единственото подобрување што би сакал да го видам во WhatsUp Gold е во интерфејсот (екран 1), главно затоа што е премногу линеарен. На пример, ќе бидат потребни до 5 кликања на копчињата Откажи и Затвори за да се врати од прозорецот Библиотека со активен монитор во работната област. Исто така, системот 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 уреди.
ПРЕПОРАКИ:Одделите за ИТ кои сакаат најсовремени способности (со исклучок на интеграцијата на АД) ќе го ценат OpManager Professional. При купување лиценци од 26 до 50 уреди, цената е речиси половина од цената на другите два производи.
КОНТАКТ ИНФОРМАЦИИ: ManageEngine, www.manageengine.com

По инсталирањето на системот OpManager, ми беше лесно да конфигурирам огромен број функции и лесно да се движите помеѓу нив. OpManager обезбедува можност за испраќање (заедно со е-пошта и СМС) директни пораки до вашата сметка на Твитер - убава алтернатива за е-пошта. Користењето на сметките на Twitter на овој начин ми овозможува да бидам во тек со она што се случува на интернет, но бидејќи мојот телефон не ѕвони кога пораките се испорачуваат од системот на Twitter, сакам да добивам и текстуални известувања за најважните настани. Можам да ги гледам праговите на кој било сервер преку пораките на Твитер и на тој начин да имам дневник на тековни настани на мрежата, но не мора нужно да ја користам оваа шема за да комуницирам критични предупредувања.

Покрај стандардните сензори, OpManager нуди технологии за следење на перформансите на SNMP развиени од продавачи како што се Dell Power-Edge, HP Proliant и IBM Blade Center. OpManager може да се интегрира и со Google Maps API за да можете да ги додавате вашите уреди на Google Map. Меѓутоа, за да го направите ова, ќе треба да купите сметка на Google Maps API Premium (освен ако не планирате да ја направите јавно достапна вашата мрежна карта) во согласност со условите за лиценцирање на бесплатната верзија на системот API на Google Maps.

За да се справи со ситуации кога администраторот добива предупредување, но не одговара на него во одреден временски период, 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: интерфејс за ipMonitor SolarWinds

Од друга страна, системот ipMonitor нема механизми за следење/таргетирање предупредувања. Ова можеби не е важно дали компанијата има единствен мрежен администратор, но поголемите ИТ одделенија веројатно ќе сметаат дека неможноста на системот да ги признае предупредувањата, да доделува примачи и да ги ресетира предупредувањата е значителен недостаток. Ако администраторите заборават да се координираат надвор од системот, може да има ситуации кога повеќе администратори го добиваат истото предупредување и почнуваат да работат на истиот проблем. Меѓутоа, за да се решат ваквите конфликти, доволно е да се развие договорен алгоритам за одговор на предупредувањата - на пример, ако ја поделите одговорноста за мрежните уреди помеѓу администраторите, тогаш нема да има прашања за тоа кој треба да се справи со одреден проблем.

Време е да се донесе одлука

Веќе сам одлучив кој од трите производи најмногу ќе одговара на мојата околина. Го избрав системот ManageEngine OpManager со лиценца од 50 уреди поради неколку причини.

Како прво, треба да можам да надгледувам што е можно повеќе параметри на мојата околина, бидејќи ова е најдобриот начин да се избегнат неочекувани неуспеси. Во овој поглед, системот OpManager е секако пред конкуренцијата. Втората причина е буџетот. Можам да продолжам да ги користам нашите стари алатки за мониторинг за вклучување/исклучување за работни станици и печатачи и на тој начин да ги избегнам трошоците за дополнителни лиценци. Конечно, навистина ми се допадна пристапот што ManageEngine го зеде за развој на OpManager за да ги искористи новите технологии и мислам дека вреди да се трошат трошоците за купување на годишен пакет за одржување и поддршка за да ви овозможи да преземате ажурирања како што производот се развива.

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

Оригинално име:Резиме на техники за следење и анализа на мрежниот сообраќај

Линк до оригиналниот текст: http://www.cse.wustl.edu/~jain/cse567-06/ftp/net_monitoring/index.html

Препораки:Обезбедениот превод не е професионален. Може да има отстапувања од текстот, неправилно толкување на одредени поими и поими и субјективно мислење на преведувачот. Сите илустрации беа вклучени во преводот без промени.

Алиша Сесил

Преглед на методи за анализа и следење на мрежниот сообраќај

Бидејќи приватните интранет на компаниите продолжуваат да растат, од клучно значење е мрежните администратори да разберат и да можат рачно да управуваат со различните видови сообраќај што патува низ нивната мрежа. Мониторингот и анализата на сообраќајот се неопходни за поефективно дијагностицирање и решавање на проблемите кога ќе се појават, со што ќе се спречи мрежните услуги да не работат долго време. Достапни се многу различни алатки кои им помагаат на администраторите да го следат и анализираат мрежниот сообраќај. Оваа статија ги разгледува методите за следење насочени кон рутер и методите за следење кои не се насочени кон рутер (активни и пасивни методи). Статијата дава преглед на трите достапни и најшироко користени методи за мрежно следење вградени во рутери (SNMP, RMON и Cisco Netflow) и дава информации за два нови методи за следење кои користат комбинација од пасивни и активни методи за следење (WREN и SCNM ).

1. Важноста на мрежното следење и анализа

Мониторингот на мрежата (мрежен мониторинг) е сложена и трудоинтензивна задача која е витален дел од работата на мрежните администратори. Администраторите постојано се трудат нивната мрежа да работи непречено. Ако мрежата се прекине дури и за краток временски период, продуктивноста во компанијата ќе се намали и (во случај на организации кои обезбедуваат јавни услуги) ќе биде загрозена самата способност за обезбедување на основни услуги. Поради ова, администраторите треба да го следат протокот на мрежниот сообраќај и перформансите низ целата мрежа и да проверат дали има безбедносни дупки.

2. Методи на следење и анализа

„Анализата на мрежата е процес на снимање на мрежниот сообраќај и брзо разгледување за да се утврди што се случило со мрежата“ - Ангела Оребауч. Следните делови дискутираат за два методи за следење на мрежата: првиот е насочен кон рутерот, вториот е не-рутер-центричен. Функционалноста за следење која е вградена во самите рутери и не бара дополнителна инсталација на софтвер или хардвер се нарекува методи базирани на рутер. Методите кои не се базираат на рутер бараат инсталација на хардвер и софтвер и обезбедуваат поголема флексибилност. И двете техники се дискутирани подолу во нивните соодветни делови.

2.1. Методи за следење базирани на рутер

Методите за следење базирани на рутер се хардкодирани во рутери и затоа имаат мала флексибилност. Подолу е даден краток опис на најчесто користените методи за такво следење. Секој метод еволуираше во текот на многу години пред да стане стандардизиран метод за следење.

2.1.1. Едноставен протокол за следење на мрежата (SNMP), RFC 1157

SNMP е протокол на апликациски слој кој е дел од протоколот TCP/IP. Им овозможува на администраторите да управуваат со перформансите на мрежата, да наоѓаат и поправаат проблеми со мрежата и да планираат развој на мрежата. Собира статистика за сообраќајот до крајниот домаќин преку пасивни сензори кои се имплементирани заедно со рутерот. Иако има две верзии (SNMPv1 и SNMPv2), овој дел опишува само SNMPv1. SNMPv2 се надоврзува на SNMPv1 и нуди голем број подобрувања, како што е додавањето протоколски операции. Друга верзија на SNMP се стандардизира. Верзијата 3 (SNMPv3) се разгледува.

За евиденција SNMP има три клучни компоненти: управувани уреди (Управувани уреди), агенти ) и системи за управување со мрежа (Системи за управување со мрежа - NMS). Тие се прикажани на сл. 1.

Ориз. 1. SNMP компоненти

Управуваните уреди вклучуваат агент SNMP и може да се состојат од рутери, прекинувачи, прекинувачи, хабови, персонални компјутери, печатачи и други ставки како овие. Тие се одговорни за собирање информации и ставање на располагање на системот за управување со мрежата (NMS).

Агентите вклучуваат софтвер кој поседува информации за управување и ги преведува тие информации во форма компатибилна со SNMP. Тие се затворени за контролниот уред.

Системите за управување со мрежа (NMS) извршуваат апликации што ги следат и контролираат уредите за управување. Процесорот и ресурсите за меморија потребни за управување со мрежата се обезбедени од NMS. За која било управувана мрежа, мора да се креира барем еден систем за управување. SNMP може да дејствува исклучиво како NMS, или агент, или може да врши свои должности, итн.

Постојат 4 главни команди што ги користи SNMP NMS за следење и контрола на управуваните уреди: операции за читање, пишување, прекинување и пресек. Операцијата за читање ги испитува променливите што се складирани од управуваните уреди. Командата за пишување ги менува вредностите на променливите што се зачувани од управуваните уреди. Операциите на пресекот имаат информации за тоа кои променливи на управувани уреди ги поддржуваат и собираат информации од поддржани табели со променливи. Операцијата за прекин се користи од управуваните уреди за да го известат NMS дека се случиле одредени настани.

SNMP користи 4 протоколски операции по редослед на работа: Get, GetNext, Set и Trap. Командата Get се користи кога NMS издава барање за информации за управувани уреди. Барањето SNMPv1 се состои од заглавие на пораката и единица за протокол за податоци (PDU). Пораките на PDU содржат информации кои се неопходни за успешно извршување на барање кое или ќе добие информации од агентот или ќе постави вредност во агентот. Управуваниот уред ги користи агентите на SNMP лоцирани на него за да ги добие потребните информации и потоа испраќа порака до NMS како одговор на барањето Вредноста на следниов пример на објект Можно е и NMS да испрати барање (операција за поставување) кога ја поставува вредноста на елементите без агенти.

Како што беше наведено претходно, SNMP е протокол на апликациски слој кој користи пасивни сензори за да му помогне на администраторот да го следи мрежниот сообраќај и перформансите на мрежата. Иако SNMP може да биде корисна алатка за мрежен администратор, тој создава потенцијал за безбедносни ризици бидејќи нема можности за автентикација. Се разликува од далечинскиот мониторинг (RMON), за кој се дискутира во следниот дел, со тоа што RMON работи на мрежното ниво и подолу, наместо на слојот на апликацијата.

2.1.2. Далечинско следење (RMON), RFS 1757

RMON вклучува различни мрежни монитори и конзолни системи за менување на податоците добиени за време на мрежното следење. Ова е продолжение на информативната база за управување со SNMP (MIB). За разлика од SNMP, кој мора да испраќа барања за информации, RMON може да конфигурира сигнали кои ќе ја „надгледуваат“ мрежата врз основа на одредени критериуми. RMON им дава можност на администраторите да управуваат со локални мрежи, како и со далечински од една специфична локација/точка. Неговите монитори за мрежниот слој се прикажани подолу. RMON има две верзии RMON и RMON2. Сепак, оваа статија зборува само за RMON. RMON2 овозможува следење на сите мрежни нивоа. Се фокусира на сообраќајот на IP и сообраќајот на апликацискиот слој.

Иако постојат 3 клучни компоненти на околината за следење RMON, само две од нив се опишани овде. Тие се прикажани на сл. 2 подолу.

Ориз. 2. RMON компоненти

Двете компоненти на RMON се сензорот, исто така познат како агент или монитор, и клиентот, исто така познат како станица за управување (контролна станица). За разлика од SNMP, RMON сензорот или агентот собира и складира информации за мрежата. Сензорот е софтвер вграден во мрежен уред (како рутер или прекинувач). Сензорот може да се работи и на персонален компјутер. Мора да се постави сензор за секој различен сегмент од локалната или широката мрежа, бидејќи тие можат да го видат сообраќајот што минува само низ нивните канали, но не се свесни за сообраќајот надвор од нивните патеки. Клиентот е типично станица за управување која комуницира со сензор кој користи SNMP за примање и корекција на податоците RMON.

RMON користи 9 различни мониторинг групи за да добие информации за мрежата.

• Статистика - статистика мерена од сензорот за секој мониторинг интерфејс за даден уред.
• Историја - сметководство за периодични статистички примероци од мрежата и нивно складирање за пребарување.
• Аларм - периодично зема статистички примероци и ги споредува со збир на прагови за да генерира настан.
• Домаќин - Содржи статистика поврзана со секој домаќин пронајден на мрежата.
• HostTopN - подготвува табели кои го опишуваат врвот на хостовите (главниот хост).
• Филтри - Овозможува филтрирање пакети врз основа на равенка на филтер за снимање настани.
• Снимање пакети - ги фаќа пакетите откако ќе поминат низ каналот.
• Настани - контролирајте го генерирањето и регистрацијата на настани од уредот.
• Токен прстен - поддршка за токени за прстени.

Како што е наведено погоре, RMON се базира на протоколот SNMP. Иако следењето на сообраќајот може да се изврши со користење на овој метод, аналитиката на информациите добиени од SNMP и RMON имаат слаби перформанси. Услужната алатка Netflow, за која се дискутира во следниот дел, успешно работи со многу аналитички софтверски пакети за да ја олесни работата на администраторот многу.

2.1.3. Netflow, RFS 3954

Netflow е екстензија што беше воведена во рутерите на Cisco која обезбедува можност за собирање на IP мрежниот сообраќај доколку е конфигуриран во интерфејсот. Со анализа на податоците обезбедени од Netflow, мрежниот администратор може да одреди работи како што се: изворот и дестинацијата на сообраќајот, класата на услугата и причините за пренатрупаноста. Netflow вклучува 3 компоненти: FlowCaching (проток за кеширање), FlowCollector (собирач на информации за проток) и Data Analyzer (анализатор на податоци). Ориз. Слика 3 ја прикажува инфраструктурата Netflow. Секоја компонента прикажана на сликата е објаснета подолу.

Ориз. 3. NetFlow инфраструктура

FlowCaching анализира и собира податоци за тековите на IP кои влегуваат во интерфејсот и ги конвертира податоците за извоз.

Следниве информации може да се добијат од Netflow пакетите:

• Адреса на изворот и дестинацијата.
• Број на дојдовни и појдовни уреди.
• Број на портата на изворот и дестинацијата.
• Протокол на ниво 4.
• Број на пакети во потокот.
• Бројот на бајти во потокот.
• Временски печат во преносот.
• Број на автономен систем (AS) на изворот и дестинацијата.
• Тип на услуга (ToS) и знаменце TCP.

Првиот пакет на проток кој минува низ стандардната патека на префрлување се обработува за да се создаде кеш. Пакетите со слични карактеристики на нишките се користат за креирање на запис во нишка што е кеширана за сите активни нишки. Овој запис го означува бројот на пакети и бројот на бајти во секој поток. Кешираните информации потоа периодично се извезуваат во Колекторот на проток.

Собирач на проток - одговорен за собирање, филтрирање и складирање на податоци. Вклучува историја на информации за нишките што биле поврзани со помош на интерфејсот. Намалувањето на волуменот на податоците се случува и со помош на Flow Collector со помош на избрани филтри и агрегација.

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

Предноста на Netflow во однос на другите методи за следење, како што се SNMP и RMON, е тоа што има софтверски пакети дизајнирани за различни анализи на сообраќајот кои постојат за да примаат податоци од Netflow пакетите и да ги презентираат во попогодна форма.

Со користење на алатки како што е Netflow Analyzer (ова е само една алатка која е достапна за анализа на пакетите Netflow), информациите погоре може да се извлечат од Netflow пакетите за да се создадат графикони и редовни графикони кои администраторот може да ги испита за подобро разбирање за неговата мрежа. Најголемата предност на користењето на Netflow, наспроти достапните аналитички пакети, е тоа што во овој случај може да се изградат бројни графикони кои ја опишуваат мрежната активност во кое било дадено време.

2.2. Технологии кои не се засновани на рутери

Иако технологиите кои не се вградени во рутерот сè уште се ограничени во нивните можности, тие нудат поголема флексибилност од технологиите вградени во рутерите. Овие методи се класифицирани како активни и пасивни.

2.2.1. Активен мониторинг

Активниот мониторинг известува за проблеми во мрежата со собирање мерења помеѓу две крајни точки. Активен систем за мерење се занимава со метрика како што се: корисност, рутери/рути, латентност на пакети, повторување на пакети, загуба на пакети, нервоза меѓу пристигнување, мерење на пропусната моќ.

Главно користењето алатки како што е командата ping, која ја мери латентноста и загубата на пакети, и traceroute, која помага да се одреди мрежната топологија, се примери за основни активни алатки за мерење. И двете од овие алатки испраќаат ICMP пакети со сонда до дестинација и чекаат таа дестинација да одговори на испраќачот. Ориз. 4 е пример за командата ping, која користи активен метод на мерење, испраќајќи барање Echo од извор преку мрежата до одредена точка. Потоа, примачот испраќа барање за Echo назад до изворот од кој дојде барањето.

Ориз. 4. ping команда (Активно мерење)

Овој метод не само што може да собере поединечни метрики за активното мерење, туку може да ја одреди и мрежната топологија. Друг важен пример за активно мерење е алатката iperf. Iperf е алатка која го мери пропусниот квалитет на протоколите TCP и UDP. Го известува капацитетот на каналот, постојното доцнење и загубата на пакети.

Проблемот што постои со активниот мониторинг е што доставените сонди на мрежата може да го попречат нормалниот сообраќај. Често времето на активните сонди се третира поинаку од вообичаениот сообраќај, со што се доведува во прашање значењето на информациите обезбедени од овие сонди.

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

2.2.2. Пасивен мониторинг

Пасивното следење, за разлика од активното следење, не додава сообраќај во мрежата или не го менува сообраќајот што веќе постои на мрежата. Исто така, за разлика од активното следење, пасивното следење собира информации за само една точка во мрежата. Мерењата се многу подобри отколку помеѓу две точки со активно следење. Ориз. Слика 5 покажува поставување на пасивен систем за следење, каде што мониторот е поставен на една врска помеѓу две крајни точки и го следи сообраќајот додека минува преку врската.

Ориз. 5. Поставување на пасивен мониторинг

Пасивните мерења се занимаваат со информации како што се: микс на сообраќај и протоколи, број на битови (брзина на битови), тајминг на пакети и време меѓу пристигнување. Пасивното следење може да се изврши со користење на која било програма што повлекува пакети.

Иако пасивното следење ги нема трошоците што ги има активното следење, тој има свои недостатоци. Со пасивно следење, мерењата може да се анализираат само офлајн и тие не ја претставуваат збирката. Ова претставува предизвик во обработката на големи множества податоци кои се собираат за време на мерењето.

Пасивното следење може да биде супериорно во однос на активното следење со тоа што не се додаваат надземни податоци на мрежата, но пост-обработката може да извлече многу време преку глава. Ова е причината зошто постои комбинација од овие два методи на следење.

2.2.3. Комбиниран мониторинг

Откако ќе ги прочитате деловите погоре, можете безбедно да дојдете до заклучок дека комбинирањето на активно и пасивно следење е подобар начин од користењето на првиот или вториот одделно. Комбинираните технологии ги користат најдобрите аспекти и на пасивните и на активните опкружувања за следење. Две нови технологии кои претставуваат комбинирани технологии за следење се опишани подолу. Тоа се „Преглед на ресурси на крајот на мрежата“ (WREN) и „Мрежен монитор за прилагодена конфигурација“ (SCNM).

2.2.3.1. Приказ на ресурси на крајот на мрежата (WREN)

WREN користи комбинација од техники за активно и пасивно следење, активно обработувајќи податоци кога сообраќајот е низок и пасивно обработува податоци за време на голем сообраќај. Го гледа сообраќајот и од изворот и од примачот, што овозможува попрецизни мерења. WREN користи траги од пакети од сообраќајот генериран од апликации за мерење на употребливиот проток. WREN е поделен на два слоја: основни слој за брзо процесирање на пакети и анализатор на траги на ниво на корисник.

Основниот слој за брза обработка на пакети е одговорен за добивање информации поврзани со дојдовните и појдовните пакети. Ориз. 6 покажува листа на информации што се собираат за секој пакет. На Web100 се додава бафер за да се соберат овие карактеристики. До баферот се пристапува со два системски повици. Еден повик започнува трага и ги обезбедува потребните информации за да се собере, додека вториот повик ја враќа трагата од кернелот.

Ориз. 6. Информации собрани на главното ниво на траги од пакети

Објект за следење на пакети- може да ги координира пресметките помеѓу различни машини. Една машина ќе активира друга машина со поставување знаме во заглавието на појдовниот пакет за да започне со обработка на одреден опсег на пакети што ги следи. Другата машина за возврат ќе ги следи сите пакети за кои гледа слично знаменце поставено во заглавието. Оваа координација осигурува дека информациите за слични пакети се складираат на секоја крајна точка, без оглед на комуникацијата и што се случува меѓу нив.

Анализаторот на трага на ниво на корисник е друго ниво во околината WREN. Ова е компонента која започнува да следи кој било пакет, ги собира и обработува вратените податоци на ниво на кернелот на операторот. Според дизајнот, компонентите на ниво на корисник не треба постојано да читаат информации од објектот за трага на пакетот. Тие може да се анализираат веднаш по завршувањето на трагата за да се извлечат заклучоци во реално време или податоците да се складираат за понатамошна анализа.

Кога сообраќајот е мал, WREN активно ќе внесе сообраќај во мрежата додека го одржува редот на мерните текови. По бројни студии, откриено е дека WREN прикажува слични мерења во презаситени и непрезаситени средини.

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

Генерално, WREN е многу корисна поставка што ги користи предностите и од активното и од пасивното следење. Иако оваа технологија е во рана фаза на развој, WREN може да им обезбеди на администраторите корисни ресурси за следење и анализа на нивните мрежи. Мрежен монитор за самоконфигурација (SCNM) е уште една алатка која користи и активни и пасивни технологии за следење.

2.2.3.2. Мрежен монитор за самоконфигурација (SCNM)

SCNM е алатка за следење која користи комбинација од пасивни и активни мерења за собирање информации за пенетрациите на слојот 3, излезните рутери и други важни точки за следење на мрежата. Околината SCNM вклучува и хардверски и софтверски компоненти.

Хардверот е инсталиран на критичните точки во мрежата. Тој е одговорен за пасивно собирање заглавија на пакети. Софтверот работи на крајната точка на мрежата. Ориз. 7 подолу ја прикажува софтверската компонента на околината SCNM.

Ориз. 7. SCNM софтверска компонента

Софтверот е одговорен за креирање и испраќање на активирани пакети кои се користат за започнување на мрежното следење. Корисниците ќе испратат пакети за активирање до мрежата кои содржат детали за пакетите што сакаат да ги добијат за следење и собирање. Корисниците не треба да ја знаат локацијата на домаќинот SCNM, под претпоставка дека сите хостови се отворени за душкање пакети. Врз основа на информациите што постојат во пакетот за активирање, филтерот се става во протокот на собирање податоци, кој исто така работи на крајната точка. Заглавјата на пакетите на мрежата и транспортниот слој што одговараат на филтерот се собрани. Филтерот автоматски ќе истече по точно одредено време доколку прими други пакети со апликации. Услугата за земање примероци на пакети, која работи на SCNM-домаќинот, ја користи командата tcpdump (слична на програмата за земање примероци на пакети) по редослед на примени барања и снимање сообраќај што одговара на барањето.

Штом проблемот ќе се идентификува со алатки за пасивно следење, сообраќајот може да се генерира со активни алатки за следење, што овозможува собирање дополнителни податоци за понатамошно испитување на проблемот. Со распоредување на овој монитор низ мрежата на секој рутер на патот, можеме да ги испитаме само деловите од мрежата што имаат проблеми.

SCNM е наменет за инсталација и употреба првенствено од администраторите. Сепак, редовните корисници можат да користат дел од оваа функционалност. Иако општите корисници можат да користат делови од околината за следење SCNM, им е дозволено само да ги прегледуваат сопствените податоци.

Како заклучок, SCNM е уште една хибридна техника за следење која користи и активни и пасивни методи за да им помогне на администраторите да ги следат и анализираат нивните мрежи.

3. Заклучок

При изборот на комерцијални алатки што ќе се користат за следење на мрежата, администраторот мора прво да одлучи дали сака да користи добро воспоставени системи што се користат многу години или нови. Ако постоечките системи се посоодветно решение, тогаш NetFlow е најкорисната алатка за користење, бидејќи во врска со оваа алатка, анализираните пакети со податоци може да се користат за да се претстават податоците на попријатен начин. Меѓутоа, ако администраторот е подготвен да проба нов систем, комбинираните решенија за следење како што се WREN или SCNM се најдобрата насока за следење.

Мониторингот и анализата на мрежата се од витално значење во работата на системскиот администратор. Администраторите треба да се обидат да ја одржуваат својата мрежа во ред, како за неразделена продуктивност во компанијата, така и за комуникација со сите постоечки јавни услуги. Врз основа на информациите опишани погоре, голем број технологии базирани на рутер и не-рутери се погодни за помош на мрежните администратори во секојдневното следење и анализа на нивните мрежи. Накратко ги опишува SNMP, RMON и NetFlow на Cisco, пример на неколку технологии базирани на рутер.

Вовед

Во последниве години, информатичката технологија претрпе значителни и постојани промени. Според некои проценки, во текот на изминатите пет години обемот на мрежниот сообраќај на локалните мрежи пораснал десет пати. Така, локалните мрежи мора да обезбедат зголемен капацитет и потребното ниво на квалитет на услугата. Сепак, без разлика со какви ресурси има мрежата, тие сè уште се конечни, така што на мрежата и е потребна способност да го контролира сообраќајот.

И за управувањето да биде што е можно поефикасно, треба да можете да ги контролирате пакетите испратени помеѓу уредите на вашата мрежа. Исто така, администраторот има многу дневни операции што мора да се извршат. Ова вклучува, на пример, проверка на правилното функционирање на е-поштата, прегледување датотеки за регистрација за да се идентификуваат раните знаци на дефекти, следење на поврзувањето на локалните мрежи и достапноста на системските ресурси. И тука алатките што се користат за следење и анализа на компјутерските мрежи можат да дојдат до помош.

За да не се мешаме во разновидноста на методи, алатки и производи создадени за следење, да започнеме со краток опис на неколку големи класи на овие производи.

Системи за управување со мрежи. Станува збор за централизирани софтверски системи кои собираат податоци за состојбата на мрежните јазли и комуникациските уреди, како и за сообраќајот што циркулира во мрежата. Овие системи не само што ја следат и анализираат мрежата, туку вршат и активности за управување со мрежата во автоматски или полуавтоматски режим - овозможување и оневозможување на портите на уредот, менување на параметрите на мостот, табели за адреси на мостови, прекинувачи и рутери итн. Примери на системи за контрола ги вклучуваат популарните системи HPOpenView, SunNetManager, IBMNetView.

Алатки за управување со системот. Системските контроли често вршат функции слични на оние на контролните системи, но во однос на различни објекти. Во првиот случај, контролниот објект е софтверот и хардверот на мрежните компјутери, а во вториот - комуникациската опрема. Сепак, некои функции на овие два типа на системи за управување може да се дуплираат, на пример, алатките за управување со системот можат да вршат едноставна анализа на мрежниот сообраќај.

Вградени системи. Овие системи се имплементирани во форма на софтверски и хардверски модули инсталирани во комуникациската опрема, како и во форма на софтверски модули вградени во оперативните системи. Тие ги извршуваат дијагностичките и контролните функции на само еден уред, и ова е нивната главна разлика од централизираните контролни системи. Пример за алатки од оваа класа е модулот за управување со хаб Distrebuted 5000, кој ги имплементира функциите на автоматско сегментирање на портите кога се откриваат грешки, доделување порти на внатрешни сегменти на хабот и некои други. Како по правило, вградените модули за управување се удвојуваат како SNMP агенти кои обезбедуваат податоци за статусот на уредот до системите за управување.

Протоколни анализатори. Тие се софтверски или хардверско-софтверски системи кои, за разлика од контролните системи, се ограничени само на функциите на следење и анализа на сообраќајот во мрежите. Добар анализатор на протоколи може да фати и декодира пакети од голем број протоколи што се користат во мрежите - обично неколку десетици. Протоколните анализатори ви дозволуваат да поставите некои логички услови за зафаќање на поединечни пакети и да извршите целосно декодирање на заробените пакети, односно, тие покажуваат во форма погодна за специјалист вгнездување на протоколарни пакети од различни нивоа едни во други со декодирање на содржината на поединечни полиња на секој пакет.

Експертски системи. Системите од овој тип го акумулираат човечкото знаење за идентификување на причините за ненормалното функционирање на мрежите и можните начини за доведување на мрежата во оперативна состојба. Експертските системи често се имплементираат како посебни потсистеми на различни алатки за следење и анализа на мрежата: системи за управување со мрежата, анализатори на протоколи, мрежни анализатори. Наједноставната верзија на експертски систем е систем за помош чувствителен на контекст. Покомплексните експертски системи се таканаречени бази на знаење кои имаат елементи на вештачка интелигенција. Пример за таков систем е експертскиот систем вграден во системот за контрола на спектарот на Каблтрон.

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

Контролни системи

Неодамна, два прилично јасно дефинирани трендови се забележани во областа на контролните системи:

1. Интеграција на функции за управување со мрежа и системи во еден производ. (Несомнената предност на овој пристап е една точка на системска контрола. Недостатокот е што со големо оптоварување на мрежата, серверот со инсталираната програма за следење можеби нема да може да ги обработи сите пакети и, во зависност од производот, или игнорирајте некои од пакетите или станете „тесно место“ на системот).
2. дистрибуција на контролниот систем, во кој има неколку конзоли во системот кои собираат информации за состојбата на уредите и системите и издаваат контролни дејства. (Овде е точно спротивното: задачите за следење се дистрибуираат меѓу неколку уреди, но можни се дуплирање на истите функции и недоследност помеѓу контролните дејства на различни конзоли.)

Често, системите за управување ги извршуваат не само функциите на следење и анализа на работата на мрежата, туку ги вклучуваат и функциите на активно влијание врз мрежата - конфигурација и управување со безбедноста (види странична лента).

Протокол за управување со мрежа SNMP

На повеќето луѓе кои градат и управуваат со мрежи им се допаѓа концептот на стандарди. Ова е разбирливо бидејќи стандардите им дозволуваат да изберат мрежен добавувач на производи врз основа на критериуми како што се ниво на услуга, цена и перформанси на производот, наместо да бидат затворени во сопствено решение од еден продавач. Најголемата мрежа на денешницата, Интернетот, се заснова на стандарди. Работната група за Интернет инженерство (IETF) беше создадена за да ги координира развојните напори за оваа и другите мрежи користејќи протоколи TCP/IP.

Најчестиот протокол за управување со мрежата е SNMP (Simple Network Management Protocol), кој е поддржан од стотици производители. Главните предности на протоколот SNMP се едноставноста, пристапноста и независноста од производителите. Протоколот SNMP е дизајниран за управување со рутери на Интернет и е дел од стекот TCP/IP.

Што е MIB - Man in Black?

Ако зборуваме за алатки за следење на корпоративна мрежа, тогаш оваа кратенка го крие терминот Менаџмент информативна база. За што служи оваа база на податоци?

SNMP е протокол што се користи за добивање информации од мрежните уреди за нивниот статус, перформанси и карактеристики, кои се складирани во посебна база на податоци за мрежни уреди наречена MIB. Постојат стандарди кои ја дефинираат структурата на MIB, вклучувајќи го множеството типови на неговите променливи (објекти во ISO терминологијата), нивните имиња и дозволените операции на тие променливи (на пример, читање). Заедно со други информации, MIB може да складира мрежни и/или MAC адреси на уреди, обработени бројачи на пакети и грешки, броеви, приоритети и информации за статусот на портата. Структурата на дрвото MIB содржи задолжителни (стандардни) поддрва; Дополнително, може да содржи приватни поддрва што му дозволуваат на производителот на паметни уреди да имплементира какви било специфични функции врз основа на неговите специфични променливи.

Агентот во протоколот SNMP е процесорски елемент кој им овозможува на менаџерите лоцирани на станиците за управување со мрежата пристап до вредностите на променливите MIB и на тој начин им овозможува да имплементираат функции за управување и следење на уредот.

Корисен додаток на функционалноста SNMP е спецификацијата RMON, која овозможува далечинска интеракција со MIB. Пред RMON, SNMP не можеше да се користи од далечина, дозволуваше само локално управување со уредите. Сепак, RMON најдобро функционира на споделени мрежи каде што може да го следи целиот сообраќај. Но, ако има прекинувач на мрежата што го филтрира сообраќајот на таков начин што е невидлив за пристаништето, освен ако не е наменет или потекнува од уред поврзан со таа порта, тогаш податоците од вашата сонда ќе страдаат.

За да се избегне ова, производителите вклучија одредена RMON функционалност во секоја порта за прекинувач. Ова е поскалабилен систем отколку систем кој постојано ги испитува сите порти за прекинувачи.

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

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

Во оваа тешка ситуација, можете да користите различни алатки и, пред сè, алатки за следење во системите за управување со мрежата, кои веќе беа дискутирани во претходните делови од статијата. Некои мерења на мрежата можат да се извршат и со софтверски броила вградени во оперативниот систем, пример за ова е компонентата Windows NTPerformanceMonitor OS; Оваа алатка е развиена за снимање на компјутерска активност во реално време. Со негова помош, можете да ги идентификувате повеќето тесни грла кои ја намалуваат продуктивноста.

PerformanceMonitor се базира на голем број бројачи кои снимаат такви карактеристики како што се бројот на процеси кои чекаат да заврши операцијата на дискот, бројот на мрежни пакети пренесени по единица време, процентот на користење на процесорот итн.

Но, најнапредната алатка за истражување на мрежата е анализатор на протоколи. Процесот на анализа на протоколот вклучува фаќање пакети кои циркулираат во мрежа кои имплементираат одреден мрежен протокол и проучување на содржината на овие пакети. Врз основа на резултатите од анализата, можно е да се направат разумни и избалансирани промени на која било мрежна компонента, да се оптимизираат нејзините перформанси и да се решат проблемите. Очигледно, за да се извлечат какви било заклучоци за влијанието на промената на мрежата, неопходно е да се анализираат протоколите пред и по извршената промена.

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

1. Снимање податоци.
2. Прикажи снимени податоци.
3. Анализа на податоци.
4. Наоѓање грешки.
5. Истражување на перформансите. Пресметка на искористување на мрежен опсег или просечно време на одговор на барање.
6. Детална студија на поединечни делови од мрежата. Содржината на работата во оваа фаза зависи од резултатите добиени од мрежната анализа.

Ова е местото каде што можеме да го завршиме нашето разгледување на теоретските точки што треба да се земат предвид при градење на систем за следење за вашата мрежа и да продолжиме кон разгледување на софтверски производи создадени за да се анализира работата на корпоративната мрежа и да се контролира.

Производи за следење и анализа

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

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

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

Третата област се алатките за глобално управување, кои се одговорни за групирање уреди и организирање на врски меѓу нив, на пример, апликации за генерирање дијаграм за мрежна топологија.

Темата на овој напис е четвртата функционална област - следење на сообраќајот. Иако алатките за конфигурација на VLAN и глобалното управување се прилично важни аспекти на мрежната администрација, генерално не е практично да се имплементираат формални процедури за управување со мрежата на една етернет мрежа. Доволно е да се спроведе темелно тестирање на мрежата по инсталацијата и одвреме-навреме да се проверува нивото на оптоварување.

Добра платформа за системи за управување со мрежа на претпријатија треба да ги има следните квалитети:

• приспособливост;
• вистинска дистрибуција во согласност со концептот клиент/сервер;
• отвореност што ви овозможува да се справите со хетерогена опрема - од десктоп компјутери до мејнфрејмови.

Првите две својства се тесно поврзани. Добра приспособливост се постигнува поради дистрибуцијата на контролниот систем. Дистрибуцијата овде значи дека системот може да вклучува неколку сервери и клиенти.

Поддршката за хетерогена опрема е пожелна наместо вистинска карактеристика на денешните системи за контрола. Ќе разгледаме два популарни производи за управување со мрежата: Спектар на CabletronSystems и OpenView на Hewlett-Packard. И двете од овие компании сами произведуваат комуникациска опрема. Секако, Spectrum најдобро функционира со опремата на Cabletron, додека OpenView најдобро функционира со опремата на Hewlett-Packard.

Ако мрежната мапа е изградена од опрема од други производители, овие системи почнуваат да прават грешки и да ги помешаат некои уреди со други, а кога управуваат со овие уреди, тие ги поддржуваат само нивните основни функции, а многу корисни дополнителни функции што го разликуваат овој уред од другите се едноставно не се разбира од системот на управување затоа не може да ги користи.

За да се избегне оваа ситуација, развивачите на контролните системи вклучуваат поддршка не само за стандардните бази на податоци MIBI, MIBII и RMONMIB, туку и за бројни приватни производители на MIB. Лидер во оваа област е системот Spectrum, кој поддржува повеќе од 1000 MIB од различни производители.

Сепак, несомнената предност на OpenView е неговата способност да ги препознае мрежните технологии на која било мрежа што работи преку TCP/IP. Со Spectrum, оваа способност е ограничена на Ethernet, TokenRing, FDDI, ATM, WAN и Switched мрежи. Како што се зголемуваат уредите на мрежата, Spectrum се покажува поскалабилен, каде што бројот на опслужени јазли е неограничен.

Очигледно е дека, и покрај присуството на слаби и силни страни во двата системи, доколку во мрежата доминира опрема од кој било производител, достапноста на апликации за управување од овој производител за која било популарна платформа за управување им овозможува на мрежните администратори успешно да решат многу проблеми. . Затоа, развивачите на платформа за управување обезбедуваат алатки кои го олеснуваат развојот на апликациите, а достапноста и количината на таквите апликации се смета за многу важен фактор при изборот на платформа за управување.

Системи за мрежи со широк опсег

Ова е сектор на евтини системи за мрежи кои не се многу критични за неуспеси и вклучува FoundationAgentMulti-Port, Foundation Probe, Foundation Manager произведен од NetworkGeneral. Тие се комплетен систем за следење на мрежата базиран на RMON и вклучуваат два типа на агенти за монитор - FoundationAgent и FoundationProbe, како и операторска конзола FoundationManager.

FoundationAgentMulti-Port ги поддржува сите можности на стандарден SNMP агент и напреден систем за собирање и филтрирање податоци, а исто така ви овозможува да собирате информации од сегментите на Ethernet или TokenRing користејќи еден компјутер.

FoundationProbe е сертифициран компјутер со сертифицирана мрежна картичка и претходно инсталиран софтвер FoundationAgent од соодветен тип. FoundationAgent и FoundationProbe вообичаено работат во режим без монитор, без тастатура, бидејќи тие се управувани од софтверот FoundationManager.

Софтверот за конзола FoundationManager е достапен во две верзии - за Windows системи и за UNIX.

Конзолата FoundationManager ви овозможува да прикажувате статистика за сите мониторирани мрежни сегменти во графичка форма, автоматски да ги одредувате просечните мрежни параметри и да реагирате на надминување на дозволените граници на параметри (на пример, стартувајте програма за ракувач, иницирате SNMP-trap и SNA-аларм), изградите графички графикон базиран на собраните податоци RMON динамичка сообраќајна карта помеѓу станиците.

Системи за дистрибуирани мрежи

Ова е сектор на скапи, висококвалитетни системи дизајнирани да ги анализираат и надгледуваат мрежите кои поставуваат највисоки можни барања за доверливост и перформанси. Вклучува DistributedSnifferSystem (DSS), кој е систем кој се состои од неколку хардверски компоненти и софтвер дистрибуирани низ мрежата за континуирана анализа на сите мрежни сегменти, вклучувајќи ги и далечинските.

Системот DSS е изграден од два типа компоненти - SnifferServer (SS) и SniffMasterConsole (SM). Етернет картички, TokenRing или сериски порт може да се користат како интерфејси за интеракција со конзолата. Така, можно е да се контролира сегмент од речиси секоја мрежна топологија и да се користат различни медиуми за интеракција со конзолата, вклучувајќи ги и модемските врски.

Софтверот SnifferServer се состои од три потсистеми - следење, интерпретација на протокол и експертска анализа. Подсистемот за следење е систем за прикажување на моменталната состојба на мрежата, кој ви овозможува да добиете статистика за секоја од станиците и мрежните сегменти за секој од користените протоколи. Останатите два потсистема заслужуваат посебна дискусија.

Функциите на потсистемот за толкување на протоколот вклучуваат анализа на заробени пакети и најцелосна можна интерпретација на секое од полињата за заглавие на пакетите и неговата содржина. NetworkGeneral го создаде најмоќниот потсистем од овој тип - ProtocolInterpreter е способен целосно да декодира повеќе од 200 протоколи од сите седум нивоа на ISO/OSI моделот (TCP/IP, IPX/SPX, NCP, DECnetSunNFS, X-Windows, протоколот SNAIBM семејство, AppleTalk, BanyanVINES, OSI, XNS, X.25, различни протоколи за работа на интернет). Во овој случај, прикажувањето на информациите е можно во еден од трите режими - општ, детален и хексадецимален.

Главната цел на системот за експертска анализа (ExpertAnalysis) е да го намали времето на застој на мрежата и да ги елиминира тесните грла на мрежата преку автоматско идентификување на аномалните појави и автоматско генерирање методи за нивно решавање.

ExpertAnalysis обезбедува она што NetworkGeneral го нарекува активна анализа. За да се разбере овој концепт, разгледајте ја обработката на истиот настан на грешка на мрежа со традиционален систем за пасивна анализа и активен систем за анализа.

Да речеме дека во 3:00 часот по полноќ се случила бура на мрежата, што предизвикало пад на системот за резервна копија на базата на податоци во 03:05 часот. До 4:00 часот бурата престанува и параметрите на системот се враќаат во нормала. Во случај на пасивен систем за анализа на сообраќајот што работи на мрежата, администраторите кои дојдоа на работа во 8:00 немаат што да анализираат освен информации за вториот дефект и, во најдобар случај, општа сообраќајна статистика за ноќта - големината на секое снимање тампон нема да дозволи складирање на целиот сообраќај, кој стана вирален преку ноќ. Веројатноста да се елиминира причината што доведе до емитувана бура во таква ситуација е исклучително мала.

Сега да ја погледнеме реакцијата на активниот систем за анализа на истите настани. Во 3:00 часот, веднаш по почетокот на емитуваната бура, системот за активна анализа детектира појава на нестандардна ситуација, го активира соодветниот експерт и ги запишува информациите што ги дава за настанот и неговите причини во базата на податоци. Во 3:05 часот се снима нова нестандардна ситуација поврзана со дефект на системот за архивирање и се евидентираат соодветните информации. Како резултат на тоа, во 08:00 часот, администраторите добиваат целосен опис на проблемите што се појавија, нивните причини и препораки за отстранување на овие причини.

Преносни системи за анализа и следење

Пренослива верзија на анализаторот, речиси слична по своите способности на DSS, е имплементирана во серијата производи ExpertSnifferAnalyzer (ESA), позната и како TurboSnifferAnalyzer. По значително пониска цена од производите од серијата DSS, ESA му обезбедуваат на администраторот исти можности како DSS со целосен размер, но само за мрежниот сегмент на кој е моментално поврзан ESA. Постојните верзии обезбедуваат целосна анализа, интерпретација на протоколот и следење на поврзаниот мрежен сегмент или меѓусегментната комуникациска линија. Поддржани се истите мрежни топологии како и за DSS системите. Вообичаено, ESA се користат за периодично скенирање на некритични мрежни сегменти каде што не е практично постојано да се користи агент за трагање.

Novell LANAlyser Protocol Analyser

LANAlyser се испорачува како мрежна картичка и софтвер што мора да се инсталира на персонален компјутер или како компјутер со веќе инсталирани картичка и софтвер.

LANAlyser има развиен удобен кориснички интерфејс, со помош на кој се поставува избраниот режим на работа. Менито ApplicationLANalyser е главното средство за конфигурирање на режимот на пресретнување и нуди избор на протоколи, филтри, иницијатори, аларми итн. Овој анализатор може да работи со протоколите NetBIOS, SMB, NCP, NCPBurst, TCP/IP, DECnet, BanyanVINES, AppleTalk, XNS, SunNFS, ISO, EGP, NIS, SNA и некои други.

Дополнително, LANalyser вклучува експертски систем кој му помага на корисникот во смена на проблеми.

Заклучок

Сите горенаведени системи се секако неопходни во мрежата на голема корпорација, но се премногу незгодни за организации во кои бројот на корисници на мрежата не надминува 200-300 луѓе. Половина од функциите на системот ќе останат неподигнати, а сметката за дистрибуција ќе ги исплаши главниот сметководител и шефот на компанијата. Покрај тоа, следењето на хардверските грешки и тесните грла на системот во мала мрежа во повеќето случаи е во рамките на можностите на еден или двајца администратори и не бара автоматизација.

Сепак, во мрежа од кој било размер, според наше мислење, треба да постои систем за анализа на мрежата во една или друга форма, благодарение на што на администраторот ќе му биде многу полесно да управува со својот бизнис.

ComputerPress 7"2001 година

АПСТРАКТ

Овој документ е технички проект за развој и имплементација на систем за следење на мрежата за јавната мрежа за пренос на податоци на градот Верхнепишминск на Геркон ДОО. Проектот спроведе студија за постоечките мрежни системи за следење, ја анализираше моменталната состојба во претпријатието и го оправда изборот на специфични компоненти на системот за следење на мрежата.

Документот содржи опис на решенија за дизајн и спецификации за опрема.

Резултатот од дизајнот се развиените решенија за имплементација и употреба на системот:

§ Целосен опис на сите фази на дизајнирање, развој и имплементација на системот;

§ Упатство за администратор на системот, вклучувајќи опис на корисничкиот интерфејс на системот.

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

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

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

1Мрежни системи за следење220100 4010002Логичка структура на мрежата220100 4010003Алгоритам на јадрото за следење и алармирање на мрежата220100 4010004Структура на мрежниот интерфејс loading analyser220100 4010 collector220100 4010000000000000000000000 Nagios interface22010 0 4010007Генерализирана структура на системот за следење на мрежата 220100 401000

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

Етернет е стандард за пренос на податоци издаден од IEEE. Дефинира како да се пренесуваат или примаат податоци од заеднички медиум за пренос на податоци. Го формира долниот транспортен слој и се користи од различни протоколи на повисоко ниво. Обезбедува брзина на пренос на податоци од 10 Mbit/sec.

Брзиот етернет е технологија за пренос на податоци со брзина од 100 Mbit/s, користејќи го методот CSMA/CD, како 10Base-T.

FDDI - Fiber Distributed Data Interface - фибер-оптички интерфејс за дистрибуиран пренос на податоци - технологија за пренос на податоци со брзина од 100 Mbit/s, со примена на методот на токен прстен.

IEEE - Institute of Electrical and Electronic Engineers (Institute of Electrical and Electronics Engineers) е организација која развива и објавува стандарди.

LAN - локална мрежа - локална мрежа, LAN. адреса - Контрола за пристап до медиуми - идентификациски број на мрежен уред, обично одреден од производителот.

RFC - Барање за коментари - збир на документи издадени од организацијата IEEE, кој вклучува опис на стандарди, спецификации итн.

TCP/IP - Протокол за контрола на пренос/ Интернет протокол - протокол за контрола на пренос/интернет протокол.

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

ОС - Оперативен систем.

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

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

DBMS - Систем за управување со бази на податоци.

Тренд - Долгорочна статистика која ви овозможува да изградите т.н.

КОМПЈУТЕР - Електронски компјутер.

ВОВЕД

Информациската инфраструктура на модерното претпријатие е комплексен конгломерат од повеќеразмерни и хетерогени мрежи и системи. За да се обезбеди нивно непречено и ефикасно функционирање, потребна е платформа за управување во обем на претпријатие со интегрирани алатки. Сепак, до неодамна, самата структура на индустријата за управување со мрежата го спречи создавањето на такви системи - „играчите“ на овој пазар бараа лидерство со издавање производи со ограничен опсег, користејќи алатки и технологии кои не беа компатибилни со системи од други продавачи.

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

Релевантноста на оваа работа се должи на фактот дека во врска со ширењето на персоналните компјутери и создавањето на автоматизирани работни станици (AWS) врз нивна основа, се зголеми важноста на локалните компјутерски мрежи (LAN), чија дијагноза е предмет на нашето истражување. Предмет на истражувањето се основните методи на организирање и спроведување на дијагностика на современите компјутерски мрежи.

„Дијагностика на локалната мрежа“ е процес на (континуирана) анализа на состојбата на информациската мрежа. Кога ќе се појави дефект на мрежен уред, се евидентира фактот за дефект, се одредува неговата локација и тип. Се пренесува порака за дефект, уредот е исклучен и заменет со резервен.

Администраторот на мрежата, кој најчесто е одговорен за спроведување на дијагностика, мора да започне да ги проучува карактеристиките на неговата мрежа веќе во фазата на нејзиното формирање, т.е. знајте го мрежниот дијаграм и детален опис на конфигурацијата на софтверот што ги покажува сите параметри и интерфејси. Специјални системи за мрежна документација се погодни за обработка и складирање на овие информации. Користејќи ги, администраторот на системот однапред ќе ги знае сите можни „скриени дефекти“ и „тесни грла“ на неговиот систем, така што во случај на итна ситуација, ќе знае што е проблемот со хардверот или софтверот, дали програмата е оштетени или грешка резултираше со активности на операторот.

Администраторот на мрежата треба да запомни дека од гледна точка на корисниците, одлучувачки е квалитетот на апликативниот софтвер на мрежата. Сите други критериуми, како што се бројот на грешки во преносот на податоци, степенот на застојот на мрежните ресурси, перформансите на опремата итн., се споредни. „Добра мрежа“ е онаа чиишто корисници не забележуваат како функционира.

Компанија

Преддипломската пракса се реализираше во компанијата Геркон ДОО во одделот за поддршка како системски администратор. Компанијата нуди услуги за пристап до Интернет во градовите Verkhnyaya Pyshma и Sredneuralsk користејќи етернет технологија и dial-up канали од 1993 година и е еден од првите даватели на интернет услуги во овие градови. Правилата за давање услуги се регулирани со јавната понуда и прописите.

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

Одделот за поддршка го решава следниот опсег на задачи во одредено претпријатие:

§ техничко-технолошка организација за обезбедување пристап до Интернет преку dial-up и наменски канали;

§ техничка и технолошка организација на безжичен интернет пристап;

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

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

§ поставување на опремата на клиентот на локацијата на давателот (колокација);

§ изнајмување на посветени и виртуелни сервери;

§ резервна копија на податоци;

§ распоредување и поддршка на корпоративни мрежи на приватни претпријатија.

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

И покрај многуте техники и алатки за откривање и решавање проблеми во компјутерските мрежи, „земјата под нозете“ на мрежните администратори сè уште е прилично несигурна. Компјутерските мрежи сè повеќе вклучуваат компоненти со оптички влакна и безжични компоненти кои ги прават бесмислени традиционалните технологии и алатки за бакарни кабли. Покрај тоа, при брзини над 100 Mbps, традиционалните дијагностички пристапи често престануваат да работат, дури и ако медиумот за пренос е обичен бакарен кабел. Сепак, можеби најзначајната промена во технологијата за компјутерско мрежно поврзување со која администраторите мораа да се соочат е неизбежната промена од етернет мрежи со споделени медиуми кон комутирани мрежи, во кои префрлените сегменти често се индивидуални сервери или работни станици.

Точно, како што се случуваа технолошките трансформации, некои стари проблеми сами се решија. Коаксијалниот кабел, кој отсекогаш бил потешко да се откријат електричните дефекти од изопачениот пар, станува реткост во корпоративните средини. Мрежите Token Ring, чиј главен проблем беше нивната различност со Ethernet (и нималку техничка слабост), постепено се заменуваат со комутирани Ethernet мрежи. Протоколите кои генерираат бројни пораки за грешка во протоколот на мрежниот слој, како што се SNA, DECnet и AppleTalk, се заменуваат со IP. Самиот оџак на IP протоколи стана постабилен и полесен за одржување, што го докажаа милиони клиенти и милијарди веб-страници на Интернет. Дури и тврдокорните противници на Microsoft мора да признаат дека поврзувањето на новиот клиент на Windows на Интернет е многу полесно и посигурно од инсталирањето на претходните TCP/IP купови од трети страни и посебен софтвер за dial-up.

Колку што многу од денешните технологии го отежнуваат решавањето проблеми и управувањето со перформансите на мрежата, ситуацијата би можела да биде уште потешка доколку технологијата на банкоматите стане широко распространета на ниво на компјутер. Позитивна улога имаше и тоа што во доцните 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 што поддржува етернет технологија од 100 Mbps и инсталираа мрежни картички способни да работат со брзина од 100 Mbps веднаш по рестартирањето на системот, тоа станува Тоа е јасно е зошто е толку тешко да се одолее на искушението да се модернизира. Во традиционалната споделена медиумска LAN мрежа, протоколниот анализатор или монитор може да го испита целиот сообраќај на даден мрежен сегмент.

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

Иако предноста на перформансите на комутирана мрежа понекогаш е суптилна, подемот на комутирани архитектури имаше катастрофални последици за традиционалните дијагностички алатки. Во високо сегментирана мрежа, анализаторите на протоколот можат да видат уникатен сообраќај само на една порта на прекинувачот, за разлика од наследената мрежна топологија каде што би можеле детално да го испитаат секој пакет во доменот на судир. Во такви услови, традиционалните алатки за мониторинг не можат да собираат статистика за сите „дијалози“, бидејќи секој „зборувачки“ пар на крајни точки, во суштина, користи своја сопствена мрежа.

Ориз. 1.2 - Префрлена мрежа

Во комутирана мрежа, протоколниот анализатор во една точка може да „види“ само еден сегмент освен ако прекинувачот е способен да пресликува повеќе порти истовремено.

За да се одржи контролата врз високо сегментираните мрежи, производителите на прекинувачи нудат различни алатки за враќање на целосната видливост на мрежата, но многу предизвици остануваат на патот. Прекинувачите кои моментално се испорачуваат обично поддржуваат пресликување на пристаништето, каде сообраќајот од една порта се дуплира на претходно неискористена порта на која е поврзан монитор или анализатор.

Сепак, „отсликувањето“ има голем број на недостатоци. Прво, само една порта е видлива во исто време, така што е тешко да се решат проблемите што влијаат на повеќе порти. Второ, пресликувањето може да ги намали перформансите на прекинувачот. Трето, дефектите на физичките слоеви обично не се репродуцираат на приклучокот за огледало, а понекогаш дури и ознаките на VLAN се губат. Конечно, во многу случаи full-duplex Ethernet врските не можат целосно да се пресликаат.

Делумно решение за анализа на збирните параметри на сообраќајот е да се користат можностите за следење на мини-RMON агентите, особено затоа што тие се вградени во секоја порта на повеќето етернет прекинувачи. Иако мини-RMON агентите не ја поддржуваат групата објекти на Capture на спецификацијата RMON II кои обезбедуваат целосна анализа на протоколот, тие сепак можат да обезбедат увид во искористеноста на ресурсите, стапките на грешки и волуменот на повеќекратни емитувања.

Некои од недостатоците на технологијата за пресликување на порти може да се надминат со инсталирање на „пасивни славини“ произведени, на пример, од Shomiti. Овие уреди се претходно инсталирани Y-конектори и овозможуваат вистинскиот сигнал, наместо регенерираниот, да се следи со протоколски анализатор или друг уред.

Следниот проблем со притискање е проблемот со карактеристиките на оптиката. Администраторите на компјутерската мрежа обично користат специјализирана опрема за оптичка мрежна дијагностика само за решавање проблеми со оптичките кабли. Конвенционалниот стандарден SNMP или софтвер за управување со уреди базиран на CLI може да ги идентификува проблемите на прекинувачите и рутерите со оптички интерфејси. И само неколку мрежни администратори се соочуваат со потребата да се дијагностицираат уредите SONET.

Што се однесува до каблите со оптички влакна, има значително помалку причини за можни дефекти во нив отколку во случајот со бакарен кабел. Оптичките сигнали не предизвикуваат преслушување што се случува кога сигналот на едниот проводник предизвикува сигнал на другиот - ова е најтешкиот фактор во дијагностичката опрема за бакарни кабли. Оптичките кабли се имуни на електромагнетниот шум и индуцираните сигнали, така што не треба да се наоѓаат подалеку од моторите на лифтот и флуоресцентните светилки, што значи дека сите овие променливи може да се елиминираат од дијагностичкото сценарио.

Јачината на сигналот, или оптичката моќност, во дадена точка е навистина единствената променлива што треба да се мери кога се решаваат проблемите на оптичките мрежи. Ако загубата на сигналот може да се одреди низ целиот оптички канал, тогаш може да се идентификува речиси секој проблем. Евтините дополнителни модули за тестери за бакарни кабли овозможуваат оптички мерења.

Претпријатијата кои имаат распоредено голема оптичка инфраструктура и самите ја одржуваат можеби ќе треба да купат рефлектометар за оптички временски домен (OTDR), кој ги извршува истите функции за оптичко влакно како и рефлектометар на временски домен (TDR) за бакарен кабел. Уредот работи како радар: испраќа импулсни сигнали долж кабелот и ги анализира нивните рефлексии, врз основа на кои идентификува дефект на проводникот или некоја друга аномалија, а потоа му кажува на експертот каде да го бара изворот на проблемот во кабел.

Иако различни добавувачи на кабли и конектори го поедноставија процесот на завршување и разгранување на оптичко влакно, тоа сепак бара одредено ниво на специјализирани вештини, а со разумни политики, претпријатието со обемна оптичка инфраструктура ќе мора да ги обучи своите вработени. Без разлика колку добро е поставена кабелската мрежа, секогаш постои можност за физичко оштетување на кабелот како резултат на некој неочекуван инцидент.

Може да се појават проблеми и при дијагностицирање на безжични LAN 802.11b. Самата дијагностика е едноставна како и во случајот со етернет мрежите базирани на хабови, бидејќи медиумот за безжичен пренос на информации се дели помеѓу сите сопственици на клиентски радио уреди. Sniffer Technologies беше првиот што понуди решение за анализа на протоколите на таквите мрежи со проток до 11 Mbps, а последователно повеќето од водечките продавачи на анализатори воведоа слични системи.

За разлика од етернет-хаб со жичени врски, квалитетот на безжичните конекции на клиентот е далеку од стабилен. Микробрановите радио сигнали што се користат во сите опции за локален пренос се слаби и понекогаш непредвидливи. Дури и малите промени во положбата на антената може сериозно да влијаат на квалитетот на поврзувањата. Пристапните точки за безжичен LAN доаѓаат со конзола за управување со уреди и ова е често поефективен дијагностички метод отколку посета на безжични клиенти и следење на пропусната моќ и условите за грешки со рачен анализатор.

Иако проблемите со синхронизацијата на податоците и инсталацијата на уредите со кои се соочуваат корисниците на персоналниот дигитален асистент (PDA) поприродно спаѓаат во одговорностите на тимот за техничка поддршка, наместо во одговорностите на мрежниот администратор, не е тешко да се предвиди дека во не премногу далечна иднина, многу такви уреди ќе се развијат од самостојни додатоци за да го надополнат компјутерот, во комплетни мрежни клиенти.

Општо земено, операторите безжична мрежа на претпријатијата ќе (или треба) да го обесхрабрат распоредувањето на премногу отворени системи во кои секој корисник во опсегот на мрежата со компатибилна интерфејсна картичка има пристап до секоја податочна рамка на системот. Безжичниот безбедносен протокол WEP (Wired Equivalent Privacy) обезбедува автентикација на корисникот, гаранција за интегритет и шифрирање на податоците, но, како што обично се случува, софистицираниот безбедносен систем ја комплицира анализата на причините за мрежните проблеми. Во безбедните мрежи со овозможен WEP, дијагностичките техничари мора да ги знаат клучевите или лозинките што ги штитат информациските ресурси и го контролираат пристапот до системот. Кога ќе се пристапи во режимот за примање на сите пакети, анализаторот на протоколот ќе може да ги види сите заглавија на рамки, но информациите содржани во нив ќе бидат бесмислени без присуство на клучеви.

При дијагностицирање на тунелирани врски, кои многу продавачи ги нарекуваат VPN за далечински пристап, проблемите што се среќаваат се слични на оние што се среќаваат при анализа на шифрирани безжични мрежи. Ако сообраќајот не минува низ тунелираниот канал, тогаш не е лесно да се утврди причината за проблемот. Ова може да биде грешка при автентикација, дефект на една од крајните точки или метеж во јавната интернет област. Обидот да се користи протоколски анализатор за да се идентификуваат грешките на високо ниво во тунелиран сообраќај би било губење напор бидејќи содржината на податоците, како и заглавијата на апликациските, транспортните и мрежните слоеви, се шифрирани. Општо земено, мерките преземени за подобрување на безбедноста на корпоративните мрежи обично го отежнуваат идентификувањето на грешките и проблемите со перформансите. Заштитните ѕидови, прокси-серверите и системите за откривање на упад може дополнително да го комплицираат решавањето проблеми.

Така, проблемот со дијагностицирање на компјутерските мрежи е релевантен и, во крајна линија, дијагностицирањето на грешки е задача на управување. За повеќето критични системи на претпријатието, долгите напори за обновување не се опција, така што единственото решение е да се користат резервни уреди и процеси кои можат да ги преземат потребните функции веднаш по појавата на неуспеси. Во некои претпријатија, мрежите секогаш имаат дополнителна резервна компонента во случај примарната компонента да не успее, т.е. n x 2 компоненти, каде што n е бројот на примарни компоненти потребни за да се обезбедат прифатливи перформанси. Ако средното време за поправка (MTTR) е доволно високо, тогаш може да биде потребен уште поголем вишок. Факт е дека времето на поправка не е лесно да се предвиди, а значителните трошоци за време на непредвидлив период на опоравување се знак за лошо управување.

За помалку критични системи, вишокот можеби не е економски изводлив, во тој случај можеби вреди да се инвестира во најефективните алатки (и обука на персоналот) за да се забрза решавањето на проблемите низ вашата фабрика. Дополнително, поддршката за одредени системи може да се нарача, или со нивно склучување договори во куќата, со користење на надворешни центри за податоци или со користење на Application Service Providers (ASP) или даватели на услуги за управување. Покрај трошоците, најзначајниот фактор што влијае на одлуката за користење услуги од трети лица е нивото на компетентност на персоналот во куќата. Мрежните администратори мора да одлучат дали одредена функција е толку тесно поврзана со специфичните цели на претпријатието што од надворешен специјалист не може да се очекува да заврши подобра работа отколку што можат да ја вршат самите вработени во компанијата.

Речиси веднаш откако беа распоредени првите корпоративни мрежи, чија сигурност остави многу да се посакува, производителите и програмерите го изнесоа концептот на „мрежи за самолекување“. Модерните мрежи се секако посигурни отколку што беа во 90-тите, но не затоа што проблемите станаа самопоправливи. Решавањето проблеми со софтверски и хардверски неуспеси во современите мрежи сè уште бара човечка интервенција и не се очекуваат фундаментални промени во оваа состојба во блиска иднина. Дијагностичките техники и алатки се добро во рамките на сегашната практика и технологија, но тие сè уште не достигнале ниво што може значително да заштеди време на мрежните администратори додека се борат со мрежните проблеми и тесните грла во перформансите.

1.1 Дијагностички софтвер

Меѓу софтверските алатки за дијагностицирање на компјутерски мрежи, можеме да ги истакнеме специјалните системи за управување со мрежата (Network Management Systems) - централизирани софтверски системи кои собираат податоци за состојбата на мрежните јазли и комуникациските уреди, како и податоци за сообраќајот што циркулира во мрежата. Овие системи не само што ја следат и анализираат мрежата, туку вршат и активности за управување со мрежата во автоматски или полуавтоматски режим - овозможување и оневозможување на портите на уредот, менување на параметрите на мостот, табели за адреси на мостови, прекинувачи и рутери итн. Примери на системи за контрола ги вклучуваат популарните системи HPOpenView, SunNetManager, IBMNetView.

Алатките за управување со системот извршуваат функции слични на оние на контролните системи, но во однос на комуникациската опрема. Во исто време, некои функции на овие два типа на системи за управување може да се дуплираат, на пример, алатките за управување со системот можат да вршат едноставна анализа на мрежниот сообраќај;

Експертски системи. Овој тип на систем го акумулира човечкото знаење за идентификување на причините за ненормалното функционирање на мрежите и можните начини за доведување на мрежата во оперативна состојба. Експертските системи често се имплементираат како посебни потсистеми на различни алатки за следење и анализа на мрежата: системи за управување со мрежата, анализатори на протоколи, мрежни анализатори. Наједноставната верзија на експертски систем е систем за помош чувствителен на контекст. Покомплексните експертски системи се таканаречени бази на знаење кои имаат елементи на вештачка интелигенција. Пример за таков систем е експертскиот систем вграден во системот за контрола на спектарот на Каблтрон.

1.1.1 Протоколни анализатори

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

За овие цели, може да се користат различни алатки, а пред сè, алатки за следење во системите за управување со мрежата, за кои веќе беше дискутирано претходно. Некои мрежни мерења може да се извршат и со софтверски броила вградени во оперативниот систем, пример за ова е компонентата Windows Performance OS; Дури и модерните тестери за кабли се способни да зафаќаат пакети и да ја анализираат нивната содржина.

Но, најнапредната алатка за истражување на мрежата е анализатор на протоколи. Процесот на анализа на протоколот вклучува фаќање пакети кои циркулираат во мрежа кои имплементираат одреден мрежен протокол и проучување на содржината на овие пакети. Врз основа на резултатите од анализата, можно е да се направат разумни и избалансирани промени на која било мрежна компонента, да се оптимизираат нејзините перформанси и да се решат проблемите. Очигледно, за да се извлечат какви било заклучоци за влијанието на промената на мрежата, неопходно е да се анализираат протоколите и пред и по извршената промена.

Протоколниот анализатор е или независен специјализиран уред или персонален компјутер, обично пренослив, од класата Htebook, опремен со специјална мрежна картичка и соодветен софтвер. Мрежната картичка и користениот софтвер мора да одговараат на мрежната топологија (прстен, автобус, ѕвезда). Анализаторот се поврзува со мрежата на ист начин како и обичен јазол. Разликата е во тоа што анализаторот може да ги прими сите пакети со податоци што се пренесуваат преку мрежата, додека обичната станица може да ги прима само оние кои се адресирани до неа. Софтверот за анализатор се состои од јадро кое ја поддржува работата на мрежниот адаптер и ги декодира примените податоци и дополнителен програмски код, во зависност од типот на топологијата на мрежата што се проучува. Дополнително, се испорачуваат голем број рутини за декодирање специфични за протоколот, како што е IPX. Некои анализатори може да вклучат и експертски систем кој може да му даде на корисникот препораки за тоа кои експерименти треба да се извршат во дадена ситуација, што може да значат одредени резултати од мерењето и како да се отстранат одредени видови мрежни дефекти.

И покрај релативната разновидност на протоколарните анализатори на пазарот, постојат некои карактеристики кои се заеднички за сите нив до еден или друг степен:

Кориснички интерфејс. Повеќето анализатори имаат развиен кориснички интерфејс, обично базиран на Windows или Motif. Овој интерфејс му овозможува на корисникот: да ги прикаже резултатите од анализата на интензитетот на сообраќајот; добиваат инстант и просечна статистичка проценка на перформансите на мрежата; поставете одредени настани и критични ситуации за следење на нивното појавување; декодираат протоколи од различни нивоа и ја прикажуваат содржината на пакетите во разбирлива форма.

Снимајте тампон. Баферите на различни анализатори се разликуваат по големина. Баферот може да се наоѓа на инсталирана мрежна картичка или може да се одвои простор за него во RAM меморијата на еден од компјутерите на мрежата. Ако тампонот се наоѓа на мрежната картичка, тогаш тој се управува во хардвер, и поради тоа се зголемува брзината на влезот. Сепак, ова го прави анализаторот поскап. Ако извршувањето на постапката за фаќање е недоволно, некои информации ќе се изгубат и анализата ќе биде невозможна. Големината на тампонот ги одредува можностите за анализа на повеќе или помалку репрезентативни примероци од заробените податоци. Но, без разлика колку е голем тампонот за фаќање, порано или подоцна ќе се наполни. Во овој случај, или фаќањето запира или полнењето започнува од почетокот на тампонот.

Филтри. Филтрите ви овозможуваат да го контролирате процесот на снимање податоци и со тоа да заштедите простор во тампон. Во зависност од вредноста на одредени полиња на пакети наведени како состојба на филтер, пакетот или се игнорира или се запишува во баферот за фаќање. Употребата на филтри значително ја забрзува и ја поедноставува анализата, бидејќи го елиминира гледањето на моментално непотребните пакети.

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

Пребарување. Некои анализатори на протокол ви дозволуваат да го автоматизирате прегледувањето на информациите во баферот и да пронајдете податоци во него врз основа на одредени критериуми. Додека филтрите го проверуваат влезниот тек за да видат дали одговара на условите на филтерот, функциите за пребарување се применуваат на податоците што веќе се акумулирани во баферот.

Методологијата за анализа може да се претстави во следните шест фази:

Снимање податоци.

Прикажи снимени податоци.

Анализа на податоци.

Наоѓање грешки. (Повеќето анализатори ја олеснуваат оваа работа со откривање на типови на грешки и идентификување на станицата од која дојде пакетот со грешки.)

Истражување на перформансите. Се пресметува стапката на искористување на пропусниот опсег на мрежата или просечното време на одговор на барање.

Детална студија на поединечни делови од мрежата. Содржината на оваа фаза е специфицирана како што продолжува анализата.

Вообичаено, процесот на анализа на протоколите трае релативно малку време - 1-2 работни дена.

Повеќето современи анализатори ви дозволуваат да анализирате неколку глобални мрежни протоколи одеднаш, како што се X.25, PPP, SLIP, SDLC/SNA, рамковно реле, SMDS, ISDN, протоколи за мост/рутер (3Com, Cisco, Bay Networks и други). Ваквите анализатори ви дозволуваат да измерите различни параметри на протоколот, да го анализирате мрежниот сообраќај, конверзија помеѓу локални и глобални мрежни протоколи, доцнење на рутерите за време на овие конверзии итн. и мерење на максимална пропусност, тестирање на квалитетот на обезбедените услуги. Заради разновидност, скоро сите WAN-протокол анализатори спроведуваат функции за тестирање за LAN и сите главни интерфејси. Некои уреди се способни да ги анализираат телефонските протоколи. И најмодерните модели можат да ги декодираат и презентираат сите седум OSI слоеви на пригоден начин. Појавата на банкомат ги наведе производителите да ги опремат своите анализатори со алатки за тестирање на овие мрежи. Таквите уреди можат да спроведат целосно тестирање на мрежите на банкомати E-1/E-3 со поддршка за следење и симулација. Збирот на сервисни функции на анализаторот е многу важен. Некои од нив, како што е можноста за далечинско управување со уредот, се едноставно незаменливи.

Така, современите WAN/LAN/DTM протокол анализатори можат да детектираат грешки во конфигурацијата на рутерите и мостовите; поставете го типот на сообраќај испратен преку глобалната мрежа; одреди го користениот опсег на брзина, оптимизирај го односот помеѓу пропусниот опсег и бројот на канали; локализирајте го изворот на неточен сообраќај; Изведете тестирање на сериски интерфејс и целосно тестирање на банкомат; врши целосно следење и декодирање на главните протоколи на кој било канал; анализира статистика во реално време, вклучувајќи анализа на локалниот мрежен сообраќај преку глобалните мрежи.

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 се организирани во хиерархија. Овие хиерархии и други метаподатоци (како што се типот и описот на променливата) се опишани од Менаџмент информативните бази (MIBs).

Денес постојат неколку стандарди за бази на податоци за управување со информации. Главните се стандардите 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 година, кога Работната група за Интернет инженерство објави RFC 1271, „Информативна база за управување со следење на далечинска мрежа“. Овој документ содржеше опис на 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 инсталиран на нив. Овие сонди (како што е Network General's Cornerstone Agent 2.5) имаат повисоки перформанси од вградените сонди и обично ги поддржуваат сите групи на податоци 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 - услови за фаќање пакети. Групата за фаќање пакети содржи бафери за фаќање до кои се испраќаат пакети чии атрибути ги задоволуваат условите наведени во групата филтри. Во овој случај, не може да се фати целиот пакет, туку, да речеме, само првите неколку десетици бајти од пакетот. Содржината на баферите за фаќање последователно може да се анализира со користење на различни софтверски алатки, откривајќи голем број на многу корисни карактеристики на мрежата. Со обнова на филтри за одредени карактеристики, можно е да се карактеризираат различни параметри за работа на мрежата.

Настан - услови за регистрирање и генерирање настани. Групата на настани одредува кога треба да се испрати аларм до апликацијата за управување, кога да се пресретнат пакетите и воопшто како да се реагира на одредени настани што се случуваат на мрежата, на пример, кога вредностите на праговите наведени во групата за аларми се надминато: дали да поставите известување за контролната апликација или само треба да го најавите овој настан и да продолжите да работите. Настаните можеби не се поврзани со подигнување на аларми - на пример, испраќањето пакет до баферот за снимање е исто така настан.

Овие групи се нумерирани по редослед, така што на пример групата Домаќини го има нумеричкото име 1.3.6.1.2.1.16.4.

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

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

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

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

Систем за управување со мрежа - хардвер и/или софтвер за следење и управување со мрежните јазли. Софтверот на системот за управување со мрежата се состои од агенти кои живеат на мрежните уреди и пренесуваат информации до платформата за управување со мрежата. Начинот на размена на информации помеѓу контролните апликации и агентите на уредите се одредува со протоколи.

Системите за управување со мрежата мора да имаат голем број на квалитети:

вистинска дистрибуција во согласност со концептот клиент/сервер,

приспособливост,

отвореност што ви овозможува да се справите со хетерогена опрема - од десктоп компјутери до мејнфрејмови.

Првите две својства се тесно поврзани. Добра приспособливост се постигнува поради дистрибуцијата на контролниот систем. Дистрибуцијата значи дека системот може да вклучува неколку сервери и клиенти. Серверите (од менаџерите) собираат податоци за моменталната состојба на мрежата од агенти (SNMP, CMIP или RMON) вградени во мрежната опрема и ги акумулираат во нивната база на податоци. Клиентите се графички конзоли управувани од мрежни администратори. Клиентскиот софтвер на системот за управување прима барања за извршување на какви било активности од администраторот (на пример, изградба на детална карта на дел од мрежата) и контактира со серверот за потребните информации. Ако серверот ги има потребните информации, тогаш веднаш ги пренесува на клиентот, ако не, тогаш се обидува да ги собере од агентите.

Раните верзии на контролните системи ги комбинираа сите функции во еден компјутер, кој беше управуван од администратор. За мали мрежи или мрежи со мала количина на управувана опрема, оваа структура се покажува доста задоволителна, но со голема количина на управувана опрема, единствениот компјутер до кој течат информации од сите мрежни уреди станува тесно грло. И мрежата не може да се справи со големиот проток на податоци, а самиот компјутер нема време да ги обработи. Дополнително, со голема мрежа обично управуваат повеќе од еден администратор, затоа, покрај неколку сервери, големата мрежа мора да има неколку конзоли на кои работат мрежните администратори и секоја конзола мора да обезбеди специфични информации што ги задоволуваат тековните потреби на одреден администратор.

Поддршката за хетерогена опрема е пожелна наместо вистинска карактеристика на денешните системи за контрола. Четири од најпопуларните производи за управување со мрежата вклучуваат спектар на 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. Употребата на универзални DBMS ја намалува брзината на контролниот систем во споредба со складирањето податоци во датотеките на оперативниот систем, но овозможува овие податоци да бидат обработени од сите апликации што можат да работат со овие DBMS.

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 интерфејсот на мобилниот телефон. Користејќи го концептот на „родител“ домаќини, лесно е да се опише хиерархијата и зависностите помеѓу сите домаќини. Овој пристап е исклучително корисен за големи мрежи бидејќи овозможува сложена дијагностика. И овој квалитет, пак, помага да се разликуваат хостовите што не работат од оние што во моментов се недостапни поради проблеми во работењето на средните врски. Нагиос може да изгради графикони на набљудуваните системи и мапи на надгледуваната мрежна инфраструктура.

Од своето искуство со работа со Нагиос, авторот може да даде пример кој покажува колку тоа е корисно во неговата лична пракса. На надворешниот мрежен интерфејс на заштитниот ѕид, загубата на пакети започнуваше на секои неколку часа. Поради дефектот изгубен е до 20 отсто од проодниот сообраќај. Откако помина една минута, другиот интерфејс повторно почна да работи како што се очекуваше. Поради лебдечката природа на овој проблем, неколку недели не беше можно да се открие зошто периодично се појавуваат краткорочни прекини при работа со Интернет. Без Нагиос, решавањето проблеми би траело долго време.

Многу администратори се запознаени со предокот на Нагиос наречен 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 работи на компјутерски компатибилни системи од семејството Intel x86, како и IA-64, AMD64, PowerPC, ARM и многу други.

Оперативниот систем ГНУ/Линукс, исто така, често вклучува програми кои го надополнуваат овој оперативен систем и апликативни програми што го прават полноправно мултифункционално оперативно опкружување.

За разлика од повеќето други оперативни системи, 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, која му претходи на објавувањето на комерцијалната верзија на GNU/Linux - меѓународна дистрибуција развиена од голема заедница програмери за некомерцијални цели. Послужи како основа за создавање на многу други дистрибуции. Се одликува со строг пристап кон вклучување на комерцијален софтвер - француско-бразилска дистрибуција, унија на поранешниот 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. Деталното разгледување на процесот на инсталација е надвор од опсегот на оваа работа.

· Апачи 2

· PHP

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

· Библиотеки за програмери на GD

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

% sudo apt-get install 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 nagios

# /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“ го конфигурира овој пакет да се прилагоди на многу видови системи.: ./configure ... ...назначете променливи на околината (на пр., CC, CFLAGS...), наведете ги како=VALUE. Видете подолу за описи на некои од корисните променливи.за опциите се наведени во загради.:

h, --помогнете да ја прикажете оваа помош и да излезете

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

Help=рекурзивен приказ на кратката помош на сите вклучени пакети

V, --верзија прикажува информации за верзијата и излез

q, -- тивко, -- тивко не печати `проверка...“ пораки

Кеш-датотека=ФИЛЕ кеш резултати од тестот во FILE

C, --config-cache алијас за `--cache-file=config.cache“

n, --no-create не креирајте излезни датотеки

Srcdir=DIR најдете ги изворите во директориумите DIR:

Prefix=PREFIX инсталирајте датотеки независни од архитектурата во PREFIX

Exec-prefix=EPREFIX инсталирај датотеки зависни од архитектурата во EPREFIXdefault, `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=ДИР инфо документација

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

Build=BUILD конфигурирајте за градење на BUILD

Домаќин=ХОСТ вкрстено компајлира за да изгради програми што ќе се извршуваат на карактеристиките на HOST:

Disable-FEATURE не вклучува FEATURE (исто како --enable-FEATURE=не)

Овозможи-FEATURE[=ARG] вклучуваат FEATURE

Disable-statusmap=оневозможува компилација на статусна мапа CGI

Disable-statuswrl=оневозможува компилација на statuswrl (VRML) CGI

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

Овозможи-DEBUG1 прикажува општи информации за пораки

Овозможи-DEBUG2 прикажува предупредувачки пораки

Овозможи-DEBUG3 прикажува закажани настани (проверки на услугата и домаќинот... итн.)

Овозможи-DEBUG4 прикажува известувања за услугата и домаќинот

Овозможи-DEBUG5 покажува SQL барања

Овозможи-DEBUGALL ги прикажува сите пораки за отстранување грешки

Enable-nanosleep овозможува користење на nanosleep (наместо спиење) во тајмингот на настани

Enable-event-broker овозможува интеграција на рутините на посредникот за настани

Enable-embedded-perl ќе овозможи вграден преведувач на Perl

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

Со-PACKAGE[=ARG] користете PACKAGE

Без-ПАКЕТ не користете ПАКЕТ (исто како --со-ПАКЕТ=не)

Со-нагиос-корисник= поставува корисничко име да работи nagios

Со-нагиос-група= го поставува името на групата да работи nagios

Со-команда-корисник= поставува корисничко име за пристап до командата

Со-команда-група= го поставува името на групата за пристап до командата

Со-пошта= Ја поставува патеката до еквивалентна програма за пошта

Со-почеток-дир= Го поставува директориумот во кој треба да се смести скриптата за почеток

Со-lockfile= Поставува патека и име на датотека за заклучена датотека

Со-gd-lib=DIR ја поставува локацијата на библиотеката gd

Со-gd-inc=DIR ја поставува локацијата на gd вклучуваат датотеки

Со-cgiurl= поставува URL-адреса за програмите cgi (не користете заостаната коса црта)

Со-htmurl= поставува URL за јавен html

Со-perlcache вклучува кеширање на внатрешно компајлирани Perl скрипти влијателни променливи на околината: C компајлер командаC компајлер flagslinker flags, на пр. -Л ако имате библиотеки во директориумот C/C++ предпроцесорски знаменца, на пр. -Јас ако имате во нестандарден директориум Претпроцесирај ги овие променливи за да ги отфрли изборите направени со „конфигурирање“ или да помогне да се најдат библиотеки и програми со нестандардни имиња/локации.

Составување на изворниот код на Nagios.

Ајде да инсталираме бинарни датотеки, скрипта за иницијализација, примери на конфигурациски датотеки и да поставиме дозволи на директориумот со надворешни команди:

# направи install-init

# направи инсталација-конфигурација

# направи инсталирај-команден режим

) Ајде да ја смениме конфигурацијата

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

Ајде да ја уредиме конфигурациската датотека /usr/local/nagios/etc/objects/contacts.cfg со кој било уредувач на текст и да ја смениме адресата на е-пошта поврзана со дефиницијата за контакт на nagiosadmin на адресата на која ќе добиваме пораки за проблеми.

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

5) Поставување на веб-интерфејсот

Ајде да ја инсталираме датотеката за конфигурација на веб-интерфејсот Nagios во директориумот Apache conf.d.

# направи 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

Компилирајте и инсталирајте приклучоци:

# ./конфигурирај --with-nagios-user=nagios --with-nagios-group=nagios

#направи инсталирај

) Стартувајте ја услугата 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 install 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 рестарт

Деталната конфигурација на модулот за пошта е опишана во Додаток Г.

4.1.2 Опис на инсталирање на системското јадро од складиштето

Како што е прикажано погоре, инсталирањето на Nagios од изворот трае значително време и има смисла само ако ви треба внимателна оптимизација на апликацијата или сакате темелно да го разберете механизмот на системот. Во производните средини, повеќето софтвери се инсталирани од складишта како претходно компајлирани пакети. Во овој случај, инсталацијата се сведува на внесување на една команда:

% sudo aptitude install 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

Дефиниравме група за контакти и додадовме корисници во оваа група. Оваа конфигурација гарантира дека сите корисници добиваат предупредување доколку нешто не е во ред со серверите за кои е одговорна групата. Сепак, треба да имате на ум дека поединечните поставки за секој корисник може да ги отфрлат овие поставки.

Следниот чекор е да ги наведете информациите за контакт и поставките за предупредување.

Датотека контакти.cfg

Покрај обезбедувањето дополнителни информации за контакт за корисниците, едно од полињата, contact_name, има и друга цел. Скриптите CGI ги користат имињата наведени во овие полиња за да одредат дали корисникот има дозвола за пристап до ресурс или не. Мора да ја конфигурирате автентикацијата врз основа на .htaccess, но исто така мора да ги користите истите имиња како погоре со цел корисниците да работат преку веб-интерфејсот.

Сега кога домаќините и контактите се конфигурирани, можете да преминете на поставување на мониторинг на поединечни услуги што треба да се следат.

Services.cfg датотека

Овде, како и во датотеката hosts.cfg за хостови, поставуваме само општи параметри за сите услуги.

Достапни се огромен број дополнителни Nagios модули, но ако сè уште нема проверка, секогаш можете сами да ја напишете. На пример, не постои модул што проверува дали Tomcat работи или не. Може да напишете скрипта што вчитува страница JSP од оддалечен Tomcat сервер и го враќа резултатот во зависност од тоа дали вчитаната страница има текст на страницата или не. (Кога додавате нова команда, мора да ја споменете во датотеката checkcommand.cfg, која не ја допревме).

Следно, за секој поединечен хост создаваме сопствена датотека со опис, во истата датотека ќе складираме описи на услугите што ќе ги следиме за овој хост. Ова е направено за погодност и логична организација.

Вреди да се напомене дека домаќините на Windows се следат преку протоколот SNMP и NSClient а што доаѓа со Нагиос. Подолу е дијаграм на неговата работа

Ориз. 4.3 - Шема за следење на домаќинот на Windows

Во исто време, хостовите *nix се следат и преку SNMP, како и приклучокот NRPE. Дијаграмот на неговото работење е прикажан на сликата

Ориз. 4.4 - Шема за следење за *nix домаќини

2.4 Приклучоци за пишување

Во прилог на пишување скрипти за иницијализација, дефинирање на хостови и услуги, беа користени следните приклучоци:

├── check_disk

├── check_dns

├── check_http

├── check_icmp

├── check_ifoperstatus

├── check_ifstatus

├── check_imap -> check_tcp

├── check_linux_raid

├── check_load

├── check_mrtg

├── check_mrtgtraf

├── check_nrpe

├── check_nt

├── check_ping

├── check_pop -> check_tcp

├── check_sensors

├── check_simap -> check_tcp

├── check_smtp

├── check_snmp

├── check_snmp_load.pl

├── check_snmp_mem.pl

├── check_spop -> check_tcp

├── check_ssh

├── check_ssmtp -> check_tcp

├── check_swap

├── check_tcp

├── check_time

Повеќето од нив доаѓаат со пакетот 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 и да прикажувате графикони за оптоварување на каналот (влезен сообраќај, појдовен сообраќај, максимум, просек) во чекори од минути, часови, денови и години во вашиот прозорец на прелистувачот.

Барања за инсталација

Следниве библиотеки се потребни за да работи МРТГ:

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

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

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

#cfgmaker @ >

По генерирањето на конфигурациската датотека, се препорачува да се провери, бидејќи може да содржи описи на интерфејси кои не треба да ги анализираме за оптоварување. Во овој случај, одредени линии во датотеката се коментираат или бришат. Пример за конфигурациска датотека MRTG е даден во Додаток М. Поради големата големина на овие датотеки, даден е само пример од една датотека.

#индексмејкер >

Индексните страници се обични html-датотеки и нивната содржина не е од особен интерес, па затоа нема смисла да се даваат примери за нив. Додатокот H покажува пример за прикажување графикони за оптоварување на интерфејсот.

Конечно, неопходно е да се организира проверка на оптоварувањето на интерфејсот на распоред. Најлесен начин да се постигне ова е користење на оперативниот систем, имено параметрите crontab.

4.5 Инсталирање и конфигурирање на модулот за собирање дневници за настани на системот

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

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

§ филтрирање на пораките не само по приоритет, туку и според нивната содржина

§ поддршка за regexps (редовни изрази)

§ пофлексибилна манипулација и организација на трупци

§ можност за шифрирање на каналот за пренос на податоци користејќи IPSec/Stunnel

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

Табела 4.1 - Поддржани хардверски платформи

x86x86_64sun sparcppc32ppc64pa-riscaix 5.2 & 5.3nononoyoneon БарањеНодебијан Etchyesysnononononofreebsd 6.1 *yeson booknononohp-uno LES 10 / OPENSUSE 10.0YESON BACKENONONONOSLES 10 SP1 / OPENSUSE 10.1YESESESNONONONONOSOLALIS 8NONOYESNONONOSOLALIS 9ON BERKNOYESNONONOSOLARIS 10 на BACKEYESESNONOWINDOWSYESYESESESNONONONONONON Забелешка: *Пристапот до базата на податоци на Oracle не е поддржан

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

Датотеките што ги опишуваат правилата и филтрите, како и конфигурацијата на оддалечените хостови се дадени во Додаток П.

Постои RFC документ кој детално го опишува протоколот за системски дневник

Ориз. 4.6 - Шема на работа на модулот за собирање на системски дневници

На клиентот домаќин, секоја поединечна апликација пишува свој дневник за настани, со што формира извор. Следно, протокот на пораки за дневници поминува низ одредување на локацијата за складирање, потоа нејзината мрежна насока се одредува преку филтри, по што, по пристигнувањето до серверот за евиденција, локацијата за складирање повторно се одредува за секоја порака. Избраниот модул има голема приспособливост и сложени конфигурациски способности, на пример, филтрите може да се разгрануваат така што пораките за системски настани се испраќаат во неколку насоки во зависност од неколку услови, како што е прикажано на сликата подолу.

Ориз. 4.7 - Филтри за разгранување

Способноста за скалирање значи дека за да се дистрибуира оптоварувањето, администраторот ќе распореди мрежа од помошни сервери за филтрирање, таканаречените релеи.

Ориз. 4.8 - Скалирање и балансирање на оптоварување

На крајот на краиштата, на најпоедноставен начин, работата на модулот може да се опише на следниов начин: домаќините на клиентите пренесуваат пораки од дневникот на настани од различни апликации до серверите за истоварување, кои, пак, можат да ги пренесат по синџир на релеи и така натаму до централните сервери за собирање.

Ориз. 4.9 - Генерализиран дијаграм на работата на модулот

Во нашиот случај, протокот на податоци не е толку голем за да се распореди систем на сервери за истоварување, па затоа беше одлучено да се користи поедноставена шема за работа клиент-сервер.

Ориз. 4.10 - Прифатена работна шема

5. ВОДИЧ ЗА СИСТЕМСКИ АДМИНИСТРАТОР

Општо земено, се препорачува системскиот администратор да се придржува до постоечката хиерархија на конфигурациски датотеки и директориуми. Додавањето нови хостови и услуги во системот за следење се сведува на создавање нови конфигурациски датотеки и скрипти за иницијализација, како што беше прикажано во Дел 5 - Развој на софтвер, така што нема смисла повторно да се опишуваат параметрите и принципите на конфигурирање на системот во оваа работа , но вреди да се навлезе во повеќе детали за интерфејсите за опис на поединечни системски модули.

5.1 Опис на системскиот веб-интерфејс

За да се изврши интерактивно следење на услугите, попогодно беше да се интегрира веб-интерфејс во системот. Веб интерфејсот е исто така добар бидејќи дава целосна слика за системот благодарение на вешто користење на графички алатки и обезбедување дополнителни статистички информации.

Кога ќе се најавите на веб-страницата Nagios, ќе биде побарано да ги внесете корисничкото име и лозинката што ги поставивме за време на процесот на поставување. Почетната страница на веб-интерфејсот е прикажана на сликата подолу.

Ориз. 5.1 - Почетна страница на системскиот веб-интерфејс

Лево е панелот за навигација, на десната страна се резултатите од различни прикази на статусот на мрежата, домаќините и услугите. Ќе не интересира првенствено делот Мониторинг. Ајде да ја погледнеме страницата „Тактички преглед“.

Ориз. 5.2 - Почетна страница на системскиот веб-интерфејс

Оваа страница содржи збирни информации за сите параметри за следење и статусот на хостовите и услугите, но доколку се појават проблеми, тие се означени во посебна боја и стануваат хиперврска што води до детален опис на проблемот; настанале. Во нашиот случај, во моментот има еден нерешен проблем меѓу сите хостови и сервиси, следете ја оваа врска (1 Unhandled Problems).

Ориз. 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-client

├── ocsinventory-сервер

├── квага

├── рутер_krivous36b

├── router_lenina58a

├── router_su

├── рутер_ur39a

├── обликувач

├── ub13_router

├── univer11_router

└──voip

Секој директориум е складиште на дневници за настани за секој поединечен домаќин.

Ориз. 5.13 - Преглед на податоци собрани од модулот за собирање дневници на системски настани

6. ОПЕРАТИВНО ТЕСТИРАЊЕ

При имплементација на системот, беше спроведено постепено тестирање на работата на секоја компонента, почнувајќи од јадрото на системот. Проширувањето на функционалноста беше извршено само по конечното прилагодување на пониските нивоа на модулите на системот за следење на мрежата во хиерархијата поради многуте зависности на различните потсистеми. Чекор по чекор, генерално, процесот на имплементација и тестирање може да се опише на следниов начин:

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

) Поставување мониторинг на далечински хостови користејќи основна функционалност на Nagios;

) Поставување модул за следење на оптоварувањето на мрежните интерфејси со помош на MRTG;

) Проширување на функционалноста на јадрото на системот и негово интегрирање со MRTG модулот;

) Поставување на модул за собирање системски дневници;

) Пишување скрипта за иницијализирање филтер за пакети за систем за следење со цел да се обезбеди безбедност на системот.

7. Информациска безбедност

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

Штетни фактори кои влијаат на работата при користење на компјутер вклучуваат:

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

· бучава;

· електромагнетно зрачење;

· електростатско поле.

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

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

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

Дизајнираната софтверска алатка е креирана да работи на постоечки сервер сместен во специјално опремена техничка просторија. Опремен е со кабелски кутии за поставување кабли. Секој сервер се снабдува со напојување ~220V, фреквенција 50Hz, со работно заземјување. Пред да влезете во напојувањето во просторијата, се поставуваат прекинувачи кои го исклучуваат напојувањето во случај на краток спој. Заштитното заземјување се врши посебно.

При поврзување на компјутер, неопходно е да се поврзе куќиштето на опремата со заштитно заземјување, така што во случај на дефект на изолацијата или поради некоја друга причина, опасниот напон на напојувањето, кога некое лице ќе го допре куќиштето на опремата, не може да создаде струја од опасна големина низ човечкото тело.

За да го направите ова, користете го третиот контакт во електричните приклучоци, кој е поврзан со заштитниот проводник за заземјување. Куќиштата на опремата се заземјуваат преку кабелот за напојување по специјално посветен проводник.

Се користат технички мерки за да се обезбеди заштита од електричен удар при допирање на телото на електрична инсталација во случај на дефект на изолацијата на деловите под напон, кои вклучуваат:

· заштитно заземјување;

· заштитно заземјување;

· заштитно исклучување.

7.2.2 Заштита од бучава

Истражувањата покажуваат дека во средини со бучава, аудитивната функција е примарно засегната. Но, ефектот на бучавата не е ограничен само на ефектот на слухот. Предизвикува забележителни промени во голем број физиолошки ментални функции. Бучавата има штетно влијание врз нервниот систем и ја намалува брзината и точноста на сензомоторните процеси, а се зголемува и бројот на грешки при решавање на интелектуални проблеми. Бучавата има забележливо влијание врз вниманието на една личност и предизвикува негативни емоции.

Главниот извор на бучава во просториите каде што се сместени компјутерите е опремата за климатизација, опремата за печатење и копирање и вентилаторите на системите за ладење во самите компјутери.

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

· употреба на тивки механизми за ладење;

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

· употреба на материјали што апсорбираат звук за простории за обложување.

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

· системска единица (ладилник (25dB), хард диск (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 Заштита од електромагнетно зрачење

Заштита од електромагнетно влијание е обезбедена со екрани со електрично спроводлива површина и употреба на монитори опремени со систем за ниско зрачење, кој го минимизира нивото на штетно зрачење, како и монитори со течни кристали, во кои електромагнетното зрачење е целосно отсутно.

7.2.4 Заштита од електростатско поле

За заштита од ефектите на електростатско полнење, се користи заземјен заштитен филтер, се користат навлажнувачи на воздух, а подовите се покриени со антистатичка обвивка. За одржување на нормализираните вредности на концентрацијата на позитивни и негативни јони во компјутерските простории, инсталирани се климатизери и уреди за јонизација на воздухот и се врши природна вентилација најмалку 10 минути по секои 2 часа работа.

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

7.3 Услови за работа

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

Опремата што се разгледува во овој тезен проект не произведува никакви штетни материи за време на работата. Така, воздушната средина во просторијата каде што се користат нема штетни ефекти врз човечкото тело и ги исполнува барањата од категоријата I работа, според ГОСТ 12.1.005-88.

Оптималните стандарди за температура, релативна влажност и брзина на воздухот во работната површина на производствените простории се стандардизирани со ГОСТ 12.1.005-88 и се прикажани во Табела 7.1.

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

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

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

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

За пресметка, го избираме одделот за поддршка во Геркон ДОО во градот Верхњаја Пишма, каде што се одвиваше развојот на овој проект:

· површината на просторијата е 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;

КЗД - коефициент земајќи го предвид затемнувањето на прозорците од спротивставените згради, 1,2;

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

Т1 - коефициент на рефлексија од површината на просторијата, 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;

К - безбедносен фактор земајќи го предвид загадувањето на воздухот, 1,3;

N - број на светилки, 15;

η - фактор на искористување на прозрачниот тек, 0,8.

Како резултат на тоа, добиваме Phi = 1340 lm, вкупниот прозрачен флукс на сите светилки е еднаков на 3740 lm, затоа, осветлувањето на лабораторијата е повисоко од минималното дозволено.

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 cm дијагонално;

· висината на ликовите на екранот е најмалку 3,8 mm;

· растојанието од очите на операторот до екранот треба да биде околу 40-80 см;

VDT мора да биде опремен со ротирачка платформа, овозможувајќи му да се движи во хоризонтални и вертикални рамнини во рамките на 130-220 mm и да го промени аголот на наклон на екранот за 10-15 степени.

Дипломскиот проект беше изведен на компјутер со ViewSonic VDT со дијагонала од 39 см. Овој монитор е направен во согласност со меѓународните стандарди и ги исполнува сите горенаведени технички барања.

Следниве барања се однесуваат на тастатурата:

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

· мат површина со рефлексија од 0,4 - 0,6 и без сјајни делови кои можат да создадат отсјај;

Проектот беше изведен на тастатура од брендот Logitech, која ги исполнува сите горенаведени барања.

Системските единици се инсталираат на работното место, земајќи го предвид лесниот пристап до дискетите и удобен пристап до конекторите и контролите на задната страна. Често користените флопи дискови се чуваат во близина на системската единица во ќелија отпорна на прав и електромагнет. Печатачот се наоѓа десно од корисникот. Испечатениот текст е видлив за операторот кога е на главната работна позиција. Чистата хартија и другите потребни материјали се чуваат во посебни прегради блиску до печатачот.

Поврзувачките кабли се поставуваат во специјални канали. Дизајнот на каналите мора да биде таков што поврзувачките конектори не го попречуваат отстранувањето на каблите.

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

Работното место на операторот е во согласност со барањата на ГОСТ 12.2.032-78 SSBT.

Просторната организација на работното место обезбедува оптимално работно држење:

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

· грбот има потпора, односот помеѓу рамото и подлактицата, како и помеѓу бутот и долниот дел на ногата, е прав агол.

Главните параметри на работното место мора да бидат прилагодливи. Ова обезбедува можност за создавање поволни услови за работа за поединец, земајќи ги предвид геоантропометриските карактеристики.

Основни параметри на работно место и мебел опремен со персонален компјутер (сл. 7.1)

Ориз. 7.1 - Работна станица за компјутерски оператор

· висина на седиштето 42 - 45 см;

· висина на тастатура од под 70 - 85cm;

· агол на навалување на тастатурата од хоризонтална 7 - 15 степени;

· растојанието на тастатурата од работ на масата е 10 - 26 см;

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

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

· растојанието на екранот од работ на масата е 50 - 75 см;

· висина на работната површина за белешки 74 - 78cm;

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

Според SanPiN 2.2.2.542-96, природата на работата на компјутерскиот оператор се смета за лесна и спаѓа во категоријата 1А.

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

7.5 Безбедност од пожари

Просторијата каде што се работеше на овој проект има категорија на опасност од пожар утврдена во NPB 105-03 - запаливи и незапаливи течности, цврсти запаливи и незапаливи материи и материјали, вклучувајќи прашина и влакна, супстанции и материјали кои можат да комуницираат со вода, кислороден воздух или едни со други само горат, под услов просториите во кои се присутни или формирани да не припаѓаат на категориите А или Б. Зграда за простории од отпорност на пожар степен I според SNiP 21-01-97.

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

· премини, излези од просториите, пристап до опрема за гаснење пожар се бесплатни;

· опремата што е во функција е во добра работна состојба и се проверува секој пат пред да започне со работа;

· По завршувањето на работата, просторијата се проверува, напојувањето е исклучено, а просторијата е затворена.

Има два излеза за итни случаи од зградите. Ширината на излезот за итни случаи (врата) е 2 m. Патеките за евакуација користат конвенционални скали и врати за нишање. На скалите нема простории, технолошки комуникации или излези за лифтови или товарни лифтови. Патеките за евакуација се опремени и со природно и со вештачко осветлување за итни случаи.

Примарно средство за гаснење пожар во просторијата се рачни апарати за гаснење пожари со јаглерод диоксид, два во просторијата.

За да се открие почетната фаза на пожар и да се извести противпожарната служба, се користи автоматски и противпожарен алармен систем (AFS). Независно ги активира инсталациите за гаснење пожар пред пожарот да достигне големи димензии и ја известува градската противпожарна служба.

Покрај системот за аларм за пожар, објектите за CC мора да бидат опремени со стационарни инсталации за гасење пожар. Примени на инсталации за гаснење пожари со гас, чие дејство се заснова на брзо полнење на просторијата со гасна супстанција за гаснење пожар, како резултат на што се намалува содржината на кислород во воздухот.

7.6 Итни случаи

Во услови на овие простории, најверојатна итна ситуација би бил пожар. Доколку дојде до пожар, неопходно е да се евакуира персоналот и да се пријави инцидентот до противпожарната служба. Планот за евакуација е претставен на слика 7.2.

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

8. ЕКОНОМСКИ ДЕЛ

Овој дел ги разгледува трошоците за развој на систем за следење на мрежата, неговата имплементација и одржување, како и поврзаните материјали и опрема.

Трошоците за проектот ги одразуваат трошоците за средства и работна сила потрошени во процесот на развој и производство (амортизација, трошоци за опрема, материјали, гориво, енергија итн.), дел од трошоците за живот на трудот (плати) и трошоците на купени системски модули.

Во процесот на активност и зголемување на обемот на испорака на услуги, се појави проблемот со проактивно откривање на неисправни и слаби точки во мрежната организација, односно задача беше да се имплементира решение кое ќе овозможи предвидување на потребата од замена или надградба на мрежните делови. пред грешките да влијаат на работата на претплатничките јазли.

Со растот на базата на клиенти и, како последица на тоа, бројот на активна опрема, се појави потребата за брзо следење на статусот на мрежата како целина и нејзините поединечни елементи детално. Пред имплементацијата на системот за следење на мрежата, мрежниот администратор мораше да се поврзе преку протоколи телнет, http, snmp, ssh итн. на секој мрежен јазол од интерес и користете ги вградените алатки за следење и дијагностика. Моментално, мрежниот капацитет е 5000 порти, 300 копчиња на ниво 2, 15 рутери и 20 внатрешни сервери.

Дополнително, преоптоварувањата на мрежата и лебдечките дефекти беа откриени само кога се појавија сериозни проблеми кај корисниците, што не дозволуваше да се направат планови за надградба на мрежата.

Сето ова доведе, пред сè, кон постојано влошување на квалитетот на понудените услуги и зголемување на оптоварувањето на системските администратори и техничката поддршка на корисниците, што повлекуваше колосални загуби.

Во согласност со моменталната состојба, беше одлучено да се развие и имплементира систем за следење на мрежата што ќе ги реши сите горенаведени проблеми, кои, сумирано, може да се изразат на следниов начин:

Неопходно е да се развие и имплементира систем за следење кој овозможува следење и на прекинувачите, на рутерите од различни производители и на серверите на различни платформи. Фокусирајте се на употребата на отворени протоколи и системи, со максимално искористување на готови развивања од фондот за слободен софтвер, што од економска гледна точка ги намалува трошоците за лиценцирање на финалниот систем на нула.

Системот мора да ги исполнува следниве економски барања:

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

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

· проширливост и приспособливост на системот (ви овозможува да го проширите опсегот на примена без прибегнување кон развој на трети лица и сопственички развој и ги намалува трошоците за лиценцирање на производи);

· стандардни средства за обезбедување дијагностички информации (ви овозможува да ги намалите трошоците за одржување на системот);

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

· способност за работа со опрема од различни производители (овозможува користење на еден софтверски производ). (За целосен список на опрема, видете Додаток Б).

Вкупно, развојот на проектот траеше 112 часа (2 недели). За реализација на овој проект ќе бидат потребни 56 часа (1 недела).

1 Пресметка на трошоците за развој на проектот

Трошоците за развој на проектот се состојат од:

· трошоци за плата;

· трошоци за амортизација на опрема и софтверски производи;

· трошоци за електрична енергија;

· режиски трошоци.

Трошоци за плати.

При пресметување на трошоците за плати, земаме предвид дека овој проект го разви едно лице: системски инженер.

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

Ајде да ги пресметаме трошоците за 1 час инженерска работа врз основа на следните податоци:

· бонус 25%;

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

· Фондот за работно време во 2010 година, согласно производствениот календар, изнесува 1988 часа;

Така, цената, земајќи го предвид регионалниот коефициент, ќе биде:

RF = 30000 * 1,25 * 1,15 * 12/1988 = 260 рубли

При пресметување на трошоците за плата, се земаат предвид одбитоците платени од акумулираните плати, односно вкупната вредност на стапката на премијата за осигурување ќе биде еднаква на максималната стапка на UST - 26%, вклучувајќи:

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

· ФССР - 2,9%

· FFOMS - 1,1%;

· ГФОМС - 2%;

· Задолжително социјално осигурување од несреќи - 0,2%.

Вкупните одбитоци ќе бидат:

CO = RF * 0,262 = 260 * 0,262 = 68 руб.

Земајќи го предвид работното време на инженерот (112 часа за развој и 56 часа за имплементација), ги пресметуваме трошоците за плата:

Плата = (112 + 56) * (RF + CO) = 168 * 328 = 55.104 рубли

Трошоци за амортизација на опрема и софтверски производи.

Како главна опрема во фазата на развој на мрежниот проект се користеа персонален компјутер и серверот AQUARIUS SERVER T40 S41. Цената на компјутерот во моментот е приближно 17.000 рубли, додека серверот е 30.000 рубли.

Така, цената на еднократните инвестиции во опрема ќе биде:

RBA = 47.000 рубли

За време на животниот век на компјутерот и серверот, нивната модернизација е дозволена и во пресметката. Одвојуваме 50% од RV за модернизација:

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

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

· пребарување на литература;

· барање решенија за дизајнирање на систем за следење на мрежата;

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

· дизајн на систем за следење на мрежата;

· извршување на документот.

Серверот се користеше при имплементација на системот и директна работа со системот.

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

Така, вкупните трошоци за опрема, земајќи ја предвид амортизацијата, ќе бидат:

OZA = RBA + RMA = 47.000 + 23.500 = 70.500 рубли

Корисниот век се претпоставува дека е 2 години. Цената на еден час работа е (под претпоставка дека бројот на работни денови во месецот е 22 и со 8-часовен работен ден):

SOHR = 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 руб.

Така, трошоците за развој и имплементација на проектот беа:

SRV = ZP + SACHRV + OZEN + NR = 55104 + 2803,92 + 48,64 + 220416 = 278372,56 рубли

3 Ефикасност

Како резултат на економските пресметки, минималната цена за развој и имплементација на систем за следење на мрежата беше поставена на 278.372,56 рубли.

Како што може да се види од пресметките, огромното мнозинство на трошоците паѓаат на материјали и опрема. Ова се објаснува со фактот дека производителите на главната опрема се странски компании и, соодветно, цените за овие производи се дадени во американски долари по курс на Централната банка на Русија + 3%. А зголемувањето на царините за увозните производи негативно се одразува и на цената за крајните потрошувачи.

За да го оправдаме независниот развој на системот, да ја споредиме неговата цена со готови решенија достапни на пазарот:

· D-Link D-View - 360.000 рубли