IT 인프라의 관리 및 모니터링은 모든 회사의 IT 부서의 주요 작업 중 하나입니다. HP 소프트웨어 솔루션은 시스템 관리자의 작업을 단순화하고 조직의 네트워크에 대한 효과적인 제어를 구성합니다.
최신 IT 인프라는 서로 다른 표준을 기반으로 운영되는 서로 다른 제조업체의 통신, 서버 및 소프트웨어 솔루션을 포함하는 복잡한 이기종 네트워크입니다. 그 복잡성과 규모는 안정적인 네트워크 운영을 보장하는 데 사용해야 하는 높은 수준의 자동화된 모니터링 및 제어 도구를 결정합니다. HP 소프트웨어 제품은 인프라(네트워크 장비, 서버 및 스토리지 시스템)에서 비즈니스 서비스 및 비즈니스 프로세스의 품질 관리에 이르기까지 모든 수준에서 모니터링 문제를 해결하는 데 도움이 됩니다.
모니터링 시스템: 무엇입니까?
IT 모니터링을 위한 최신 플랫폼에는 모니터링을 새로운 수준으로 발전시키고 가져오기 위한 3가지 방향이 있습니다. 첫 번째는 "The Bridge"("Umbrella System", "Manager of Managers")라고 합니다. 그 개념은 인프라의 개별 부분을 모니터링하는 작업을 수행하고 시스템 자체를 정보 에이전트로 바꾸는 기존 시스템에 대한 투자를 활용하는 것입니다. 이 접근 방식은 기존 IT 인프라 모니터링의 논리적 개발입니다. "브리지" 유형 시스템 구현을 위한 전제 조건으로 IT 부서는 전체 그림을 표시할 수 없는 이종 시스템 모니터링 IT 서비스/시스템으로의 전환을 위해 이종 모니터링 시스템을 통합하기로 결정할 수 있습니다. , 심각한 애플리케이션 장애, 다수의 경고 및 경보, 균일한 적용 범위 부족, 우선 순위 지정 및 원인 식별을 진단하지 않은 경우.구현 결과는 IT 인프라의 사용 가능한 모든 이벤트 및 메트릭의 자동 수집, 해당 상태의 비교 및 서비스의 "상태"에 대한 영향이 될 것입니다. 장애가 발생한 경우 운영자는 문제 해결을 위한 권장 사항과 함께 장애의 근본 원인을 표시하는 패널에 액세스할 수 있습니다. 일반적인 오류가 발생한 경우 필요한 운영자 작업을 자동화하는 스크립트를 할당할 수 있습니다.
다음 트렌드는 Anomaly Analytics라고 합니다. 여기에서는 첫 번째 경우와 마찬가지로 여러 인프라 모니터링 시스템에서 메트릭 및 이벤트를 수집하고 추가로 IT 및 보안 로그 수집을 구성합니다. 따라서 1분마다 엄청난 양의 정보가 축적되고 회사는 그 정보를 처분함으로써 이익을 얻고자 합니다. Anomaly Analytics를 구현하는 데에는 여러 가지 이유가 있습니다. 시기적절한 수집, 모든 데이터의 저장 및 분석의 복잡성, 알려지지 않은 문제를 사후적으로 제거해야 하는 필요성, 문제 해결을 위한 중요한 정보를 신속하게 식별할 수 없음, 수동 검색의 복잡성 개별 로그에 대한 작업, 그리고 편차 및 반복적인 충돌을 식별할 필요가 있습니다.
시스템을 구현하면 이벤트, 메트릭 및 로그를 자동으로 수집하고, 필요한 기간 동안 이 정보를 저장하고, 로그, 성능 정보 및 시스템 데이터를 포함한 모든 정보를 분석할 수 있습니다. 또한 모든 유형의 문제를 예측 및 해결하고 알려진 장애를 예방할 수 있습니다.
그리고 마지막으로 - "응용 프로그램 성능 관리" 또는 최종 사용자의 트랜잭션에서 오류를 식별하고 수정합니다. 이 솔루션은 이전 두 가지와 긴밀하게 협력하여 유용한 추가 기능이 될 수 있습니다. 게다가, 그러한 시스템 자체도 구현으로부터 빠른 결과를 얻을 수 있습니다. 이 경우 회사에는 비즈니스 크리티컬 애플리케이션이 있습니다. 동시에 서비스의 가용성과 품질이 중요하며 핵심 요소 중 하나는 애플리케이션(인터넷 뱅킹, CRM, 청구 등)입니다. 이 서비스의 제공 가능성이나 품질이 떨어지면 일반적으로 사전 예방과 빠른 복구로 귀결됩니다. 이러한 시스템은 일반적으로 애플리케이션 서비스 및 성능의 가용성을 높이고 평균 복구 시간을 줄여야 할 때 구현됩니다. 또한 이 접근 방식은 SLA(서비스 수준 계약)와 관련된 불필요한 비용 및 위험을 제거하고 고객 포기를 방지(비즈니스 보호)하는 데 좋습니다.
주요 업무에 따라 수행 결과가 다를 수 있습니다. 일반적으로 이를 통해 다른 지역/네트워크 세그먼트의 "로봇"에 의한 일반적인 사용자 작업의 구현, "미러링된" 트래픽 분석, 병목 현상을 식별하여 서비스의 가용성 및 품질 확인, 운영자에게 작동성 복원 필요성에 대해 알립니다. 저하되는 장소를 나타냅니다. 필요한 경우 애플리케이션의 운영을 심층적으로 진단하여 서비스의 체계적인 열화 원인을 찾는 것이 가능하게 됩니다.
위의 접근 방식은 HP 소프트웨어 제품을 사용하여 구현할 수 있으며 이에 대해서는 아래에서 설명합니다.
HP의 "브리지"
HP Operations Bridge는 최신 세대의 우산 모니터링 시스템을 소개합니다. 이 솔루션은 독점 에이전트, 다양한 HP 소프트웨어 모니터링 모듈 및 타사 모니터링 도구의 모니터링 데이터를 결합합니다. 모든 정보 소스의 이벤트 흐름은 리소스 서비스 모델에 중첩되고 상관 메커니즘이 적용되어 어떤 이벤트가 원인, 증상 및 결과인지 결정합니다.
별도로, 우리는 자원 서비스 모델, 더 정확하게는 모델에 대해 고민해야 합니다. 다른 각도에서 정보를 분석하기 위해 그러한 모델이 무제한일 수 있기 때문입니다. 그 완전성과 관련성은 이벤트 흐름의 상관 관계를 수행하는 솔루션의 능력에 달려 있습니다. 모델의 관련성을 유지하기 위해 에이전트 및 에이전트 없는 기술을 기반으로 하는 인텔리전스 도구를 사용하여 서비스 구성 요소, 이들 간의 관계 및 서로에 대한 상호 영향에 대한 자세한 정보를 얻습니다. 모니터링 시스템과 같은 외부 소스에서 서비스 토폴로지에 대한 데이터를 가져올 수도 있습니다.
또 다른 중요한 측면은 관리의 용이성입니다. 복잡하고 동적으로 변화하는 환경에서는 시스템의 구조가 변경되고 새로운 서비스가 추가될 때 모니터링 시스템을 조정하는 것이 중요합니다. Operations Bridge에는 모니터링 자동화 구성요소가 포함되어 있어 서비스 자원 모델의 데이터가 사용되는 모니터링 경계에 입력된 시스템을 자동으로 구성할 수 있습니다. 동시에 이전에 설정한 모니터링 설정의 구성 및 변경을 지원합니다.
이전에는 관리자가 동일한 유형의 인프라 구성 요소(예: Windows, Linux 또는 UNIX 서버의 메트릭)에 대해 동일한 설정을 수행할 수 있었는데, 이는 많은 시간과 노력이 소요되었지만 이제는 동적으로 중앙에서 임계값을 구성할 수 있습니다. 서비스 또는 서비스 컨텍스트의 메트릭입니다.
애플리케이션 분석
모니터링에 대한 기존 접근 방식을 사용하는 것은 처음에 모니터링할 매개변수와 모니터링할 이벤트를 알고 있음을 의미합니다. IT 인프라 개발의 복잡성과 역학이 증가함에 따라 시스템 운영의 모든 측면을 제어하기가 점점 더 어려워짐에 따라 다른 접근 방식을 찾아야 합니다.HP Operations Analytics를 사용하면 로그 파일, 원격 측정, 비즈니스 및 성능 메트릭, 시스템 이벤트 등 애플리케이션 작동에 대한 모든 데이터를 수집 및 저장할 수 있으며 분석 엔진을 사용하여 추세 및 예측을 식별할 수 있습니다. 이 솔루션은 수집된 데이터를 단일 형식으로 가져온 다음 로그 파일의 데이터를 기반으로 상황에 맞는 선택을 하여 타임라인에 무슨 일이 일어났는지, 어떤 순간에 어떤 시스템에서 표시되는지 표시합니다. 이 제품은 여러 형태의 데이터 시각화(예: 대화식 "열 지도" 및 로그 파일 관계 토폴로지)를 제공하고 도우미 기능을 사용하여 이벤트 또는 이벤트 컨텍스트에서 특정 기간 동안 수집된 전체 데이터 세트를 찾습니다. 검색창에 입력한 검색어로 이를 통해 운영자는 오류의 원인을 이해하고(또는 HP OA 데이터와 함께 HP SHA 데이터를 사용할 때 예측을 수행) 오류의 원인과 근본 원인을 모두 식별할 수 있습니다. HP Operations Analytics는 장애가 발생한 시점의 서비스 및 환경을 재현하고 컨텍스트와 시간에서 분리하는 기능을 제공합니다.
또 다른 분석 도구는 HP Service Health Analyzer입니다. HP SHA는 가능한 서비스 거부 또는 프로비저닝의 지정된 매개변수 위반을 방지하기 위해 모니터링되는 인프라 요소의 비정상적인 동작을 감지합니다. 이 제품은 HP BSM 토폴로지 서비스 자원 모델을 기반으로 통계 데이터 분석을 위한 특수 알고리즘을 사용합니다. 그들의 도움으로 소프트웨어 및 하드웨어 플랫폼과 서비스 상태를 특성화하는 다른 BSM 모듈(예: HP RUM, HP BPM)에서 수집된 성능 매개변수의 일반 값 프로필을 구성할 수 있습니다. 일반적인 매개 변수 값은 요일과 시간을 고려하여 이러한 프로필에 입력됩니다. SHA는 축적된 데이터의 이력 및 통계 분석(식별된 데이터의 본질을 이해하기 위해)을 수행하고 기존 동적 프로필과 비교(기준선 설정)도 수행합니다.
애플리케이션 성능 모니터링
애플리케이션 성능 모니터링과 관련하여 HP 솔루션의 다음 구성 요소가 강조 표시되어야 합니다.- HP 실제 사용자 모니터링(HP RUM) - 실제 사용자의 트랜잭션 통과 제어.
- HP BPM(비즈니스 프로세스 모니터링) - 사용자 작업을 에뮬레이션하여 응용 프로그램 가용성을 제어합니다.
- HP 진단 - 응용 프로그램 내부의 요청 통과를 모니터링합니다.
HP RUM은 네트워크 트래픽을 구문 분석하여 실제 사용자의 트랜잭션을 식별합니다. 이 경우 클라이언트 부분, 응용 프로그램 서버 및 데이터베이스와 같은 응용 프로그램 구성 요소 간의 데이터 교환을 제어할 수 있습니다. 이를 통해 사용자 활동, 다양한 트랜잭션의 처리 시간을 추적하고 사용자 작업과 비즈니스 메트릭 간의 관계를 결정할 수 있습니다. HP RUM을 사용하여 모니터링 서비스 운영자는 서비스 가용성 문제에 대한 즉각적인 알림과 사용자가 발생한 오류에 대한 정보를 즉시 받을 수 있습니다.
HP BPM은 모니터링되는 시스템에 대한 실제 트랜잭션과 구별할 수 없는 합성 사용자 트랜잭션을 수행하는 활성 모니터링 도구입니다. HP BPM의 모니터링 데이터는 실제 SLA를 계산하는 데 유용합니다. "로봇"이 동일한 시간 간격으로 동일한 검사를 수행하여 일반적인(또는 가장 중요한) 요청 처리에 대한 일정한 품질 제어를 보장하기 때문입니다. 여러 위치(예: 다른 회사 사무실)에서 합성 트랜잭션을 수행하도록 프로브를 구성하면 위치 및 통신 채널을 고려하여 다양한 사용자의 서비스 가용성을 평가할 수도 있습니다. HP BPM은 VuGen(가상 사용자 생성기)을 사용하여 널리 사용되는 부하 테스트 제품인 HP LoadRunner에서도 사용되는 활동을 에뮬레이트합니다. VuGen은 다양한 프로토콜과 기술을 지원하므로 거의 모든 서비스의 가용성을 제어할 수 있을 뿐만 아니라 테스트 및 모니터링에 단일 스크립트 세트를 사용할 수 있습니다.
서비스 실패 또는 속도 저하의 원인이 Java, .NET 등과 같은 기술에 있는 경우 HP 진단이 도움이 될 수 있습니다.
이 솔루션은 Windows, Linux 및 Unix 플랫폼에서 Java, .NET, Python에 대한 심층 제어를 제공합니다. 이 제품은 다양한 애플리케이션 서버(Tomcat, Jboss, WebLogic, Oracle 등), MiddleWare 및 데이터베이스를 지원합니다. HP 진단 전문 에이전트는 응용 프로그램 서버에 설치되고 기술별 데이터를 수집합니다. 예를 들어, Java 응용 프로그램의 경우 실행 중인 쿼리, 사용 중인 메서드 및 처리하는 데 걸리는 시간을 확인할 수 있습니다. 응용 프로그램의 구조가 자동으로 그려지고 구성 요소가 어떻게 관련되어 있는지 명확해집니다. HP 진단은 복잡한 애플리케이션 전반의 비즈니스 트랜잭션을 추적하고 병목 현상을 식별하며 전문가에게 의사 결정에 필요한 정보를 제공합니다.
다음 지역에 HP 솔루션 배포
27.06.2011 네이트 맥아몬드
Ipswitch의 WhatsUp Gold Premium, ManageEngine의 OpManager Professional, SolarWinds의 ipMonitor의 세 가지 후보를 선택했습니다. 이 네트워크 스캐너는 각각 3,000달러(장치 100개당)를 넘지 않으며 선택한 제품을 무료로 테스트할 수 있는 평가판 기간이 있습니다.
저는 중견기업에서 일하고 있으며 약 7년 동안 동일한 네트워크 모니터링 시스템을 사용하고 있습니다. 서버 및 서비스 가용성에 대한 기본 정보를 관리자에게 제공하고 문제가 발생할 경우 SMS 문자 메시지를 휴대폰으로 보냅니다. 시스템을 업데이트하거나 더 나은 성능을 제공하고 네트워크에서 호스팅되는 터미널 서버, Exchange 시스템 및 SQL 시스템의 상태에 대한 자세한 정보를 제공할 수 있는 효과적인 도구를 최소한 추가해야 한다는 결론에 도달했습니다. . ... 우리 후보들을 비교해보자.
발견 프로세스
테스트를 준비하기 위한 첫 번째 단계는 Windows 서버를 포함한 모든 장치에서 SNMP 서비스를 활성화하는 것이었습니다. SNMP 서비스 설정을 변경하여 모니터링 프로세스가 다루어야 하는 모든 장치에 읽기 전용 액세스를 설정했습니다. Windows Server 2003/2000 시스템에서는 프로그램 추가/제거 창의 Windows 구성 요소 마법사를 사용하여 SNMP를 설치하고 Windows Server 2008에서는 서버 관리자 마법사를 사용하여 SNMP 구성 요소를 추가합니다. 마법사를 완료한 후에는 제어판 폴더에 있는 서비스 스냅인을 시작하고 SNMP 서비스를 구성해야 합니다. 간단합니다. 방화벽, 스위치, 라우터 및 프린터와 같은 관리되는 네트워크 장치에도 SNMP 서비스 관리가 있으며 구성 프로세스는 일반적으로 매우 간단합니다. SNMP에 대한 자세한 내용은 단순 네트워크 관리 프로토콜(technet.microsoft.com/en-us/library/bb726987.aspx)을 참조하십시오.
다음으로 Windows XP SP3이 설치된 두 작업 시스템 중 하나에 세 모니터링 시스템을 모두 설치했습니다. 일단 설치되면 각 시스템은 데이터베이스와 웹 서버의 두 부분으로 구성됩니다. 선택한 각 시스템은 여러 관리자가 웹 인터페이스를 통해 관리할 수 있으며 다양한 액세스 수준으로 계정을 구성할 수 있습니다. 세 시스템의 공통점은 각 사용자가 자신의 작업 공간에서 패널을 추가, 제거 및 이동할 수 있다는 것입니다. 패널에는 네트워크의 다른 장치에 대한 CPU 부하 또는 메모리 사용량과 같은 동일한 유형의 데이터가 표시됩니다.
네트워크 스캔(검색 프로세스라고 함)을 시작하기 전에 네트워크에서 검색된 장치에 액세스하기 위해 각 시스템이 사용해야 하는 계정 매개변수를 설정합니다. 비교 표에서 볼 수 있듯이 Ipswitch WhatsUp Gold Premium을 사용하면 SNMP, WMI, Telnet, SSH, ADO 및 VMware 서비스에 대한 계정을 구성할 수 있습니다. ManageEngine OpManager Professional은 SNMP, WMI, Telnet, SSH 및 URL을 지원하는 반면 SolarWinds ipMonitor는 SNMP, WMI 및 URL을 지원합니다.
각 네트워크 모니터링 시스템에 대한 네트워크 장치 및 계정(Windows 및 SNMP)에서 SNMP 서비스를 구성한 후 로컬 네트워크의 IP 주소 범위에 대한 검색 프로세스를 시작했습니다. 모든 시스템에서 약 70개의 장치를 감지했습니다. 기본 스캔 설정을 사용하여 테스트 중인 시스템은 장치 유형을 식별하는 데 잘 수행되었으며 장치 상태에 대한 자세한 정보를 제공했습니다. 세 시스템 모두 CPU 사용률, 메모리 사용률, 디스크 사용률/충만, 패킷 손실/대기 시간, Exchange 서비스 상태, Lotus, Active Directory 및 모든 Windows 서비스와 같은 기본 장치 및 서버 성능에 대한 센서를 포함합니다. 각 시스템에는 개별 장치와 대규모 장치 그룹에 대한 센서를 추가할 수 있는 기능이 있었습니다.
OpManager 및 WhatsUp Gold에는 서버 및 게스트에서 VMware 서비스 이벤트를 식별하고 수집하기 위한 인터페이스가 있습니다. 또한 두 제품 모두 관리되는 스위치의 서로 다른 포트에 연결된 장치를 보여주는 스위치 포트 관리자 폴링 기능이 있습니다. 얻은 정보는 서버실에서 케이블을 수동으로 추적할 필요 없이 스위치의 포트가 특정 비즈니스 응용 프로그램에 연결되는지 확인하는 데 도움이 됩니다. 나중에 특정 스위치 포트에 대한 경고를 구성할 수 있습니다. OpManager 패키지로 작업할 때 포트 폴링 결과를 얻으려면 스위치를 선택하고 스위치 포트 매퍼 도구를 실행하기만 하면 됩니다. 시스템은 몇 초 안에 결과를 반환합니다. WhatsUp Gold에 포함된 유사한 도구를 MAC 주소라고 하며 연결 가져오기 옵션을 선택한 상태에서 실행해야 합니다. WhatsUp Gold는 장치를 스캔하고 전체 네트워크의 연결에 대한 정보를 수집하려고 하기 때문에 결과를 얻는 데 시간이 더 오래 걸립니다.
입스위치 왓츠업 골드 프리미엄
입스위치 왓츠업 골드 프리미엄
당:세 경쟁자 중 가장 정확한 결과를 제공하고, 자체 센서를 생성할 수 있으며, VMware 시스템을 위한 포괄적인 모니터링 도구를 제공하고, AD와 통합됩니다.
에 맞서:경쟁사에 비해 내장 센서 수가 적고 비용이 높습니다(500개 미만의 장치에 대한 라이선스를 구매하는 경우).
등급: 5점 만점에 4.5점.
가격: 500개 장치에 대해 $7495, 100개 장치에 대해 $2695, 25개 장치에 대해 $2195입니다.
권장 사항: 대규모 VMware 환경에 서비스를 제공하거나 자체 센서를 구축하려는 IT 부서에 WhatsUp Gold를 추천합니다.
연락처 정보:입스위치, www.ipswitch.com
IpMonitor 및 OpManager 시스템으로 작업할 때 때때로 나를 당황하게 하는 이해할 수 없는 판독값을 접했습니다. IpMonitor에서 대시보드는 CPU 사용률이 크게 떨어지면 음수 값을 표시할 수 있습니다. 또 다른 경우에는 프로세서 부하가 0에 가까웠을 때 IpMonitor 시스템에서 프로세서가 11.490%에서 사용되었다는 알림을 보냈습니다! 도메인 컨트롤러의 디스크 사용량에 대한 정확한 정보를 추적하고 나에게 보내는 OpManager 시스템은 경우에 따라 최대 디스크 공간 사용량을 가진 10개의 서버 목록에 컨트롤러가 포함되지 않았습니다. 동시에 인접한 패널은 내 도메인 컨트롤러 중 하나가 상위 10위 안에도 들어가지 않고 상위 3위 안에 들어야 한다고 발표했습니다. WhatsUp Gold를 사용할 때 그런 상황이 발생하지 않았습니다. WhatsUp Gold는 대시보드에서 프로세서 코어 사용률을 모니터링하고 WhatsUp Gold 대시보드의 결과를 Windows 성능 모니터와 비교했을 때 각 코어에 정확히 일치했습니다. 마찬가지로 하드 디스크 사용에 대한 정보는 작업 공간의 모든 관련 응용 프로그램에 올바르게 보고되었습니다.
WhatsUp Gold에는 기존 센서에서 새로운 센서를 구축할 수 있는 내장 센서 라이브러리가 있습니다. 대규모 조직에서는 이 기능을 사용하여 다양한 유형의 장치를 모니터링하는 단일 센서 세트를 생성할 수 있으므로 유용할 수 있습니다. 이는 장치 그룹에 대한 센서를 구성하는 가장 효율적인 방법입니다.
WhatsUp Gold에는 Dell, HP 및 IBM 장치용 자체 센서를 사용하는 OpManager 제품군과 달리 개별 장치 제조업체용 센서(APC UPS 전원 공급 장치용 센서 제외)가 없지만 다음과 같은 센서를 생성할 수 있습니다. 액티브 스크립트. 이 유형을 사용하면 VBScript 및 JScript 프로그래밍 언어를 사용하여 자체 모니터링 프로세스를 개발할 수 있습니다. Active Script 센서에는 WhatsUp Gold 사용자가 사전 구축된 스크립트를 검색하고 다운로드할 수 있는 온라인 지원 센터가 있습니다.
WhatsUp Gold에 추가하고 싶은 유일한 개선 사항은 인터페이스(그림 1)가 너무 선형적이기 때문입니다. 예를 들어, 활성 모니터 라이브러리 창에서 작업 공간으로 돌아가려면 취소 및 닫기 버튼을 최대 5번 클릭해야 합니다. 또한 WhatsUp Gold 시스템에는 사이트의 상태를 확인하는 센서(물론 수동으로 작성하지 않는 한)가 없으며 특히 사이트가 타사 서버에서 호스팅되는 경우 필요할 수 있습니다. 다른 방법으로 액세스할 수 없습니다.
.jpg) |
| 그림 1: WhatsUp Gold 프리미엄 인터페이스 |
일정 시간 동안 장치가 유휴 상태였던 상황을 처리하기 위해 2분, 5분 및 20분마다 알림을 보내도록 설정할 수 있습니다. 이런 식으로 일정 시간 동안 중요한 노드의 응답이 없는 경우 관리자의 주의를 끌 수 있습니다.
WhatsUp Gold는 LDAP 환경에 통합할 수 있는 기능이 있는 검토 중인 유일한 시스템입니다. 이는 대규모 네트워크용 솔루션을 선택할 때 중요할 수 있습니다.
ManageEngine OpManager
ManageEngine OpManager
당:세 가지 제품 중 최고의 사용자 인터페이스; 다른 두 시스템보다 더 많은 내장 센서; 50개 이하의 장치에 대한 라이선스를 구매할 때 가장 낮은 가격입니다.
에 맞서:테스트 중에 모든 장치 표시기가 올바르게 표시되지는 않았습니다. 시스템이 완전히 작동하도록 디버그하는 데 시간이 걸릴 수 있습니다.
등급: 5점 만점에 4.5점.
가격: 100개 장치에 대해 1995달러, 50개 장치에 대해 995달러, 25개 장치에 대해 595달러.
권장 사항:기본적으로 최대한 활용하고자 하는 IT 부서(AD 통합 제외)는 OpManager Professional을 높이 평가할 것입니다. 26-50개 장치 범위의 라이선스를 구입하면 비용이 다른 두 제품 비용의 거의 절반입니다.
연락처 정보: ManageEngine, www.manageengine.com
OpManager를 설치한 후 수많은 기능으로 구성하기 쉽고 탐색하기 쉽다는 것을 알게 되었습니다. OpManager는 트위터 계정으로 쪽지를 (이메일 및 SMS와 함께) 보낼 수 있는 기능을 제공합니다. 이는 이메일에 대한 훌륭한 대안입니다. 이런 식으로 Twitter 계정을 사용하면 네트워크에서 일어나는 일을 알 수 있지만 Twitter 시스템에서 메시지가 전달될 때 내 전화가 울리지 않기 때문에 가장 중요한 이벤트에 대한 문자 알림을 동시에 받고 싶습니다. Twitter 메시지를 사용하여 모든 서버의 임계값 정보를 볼 수 있으므로 네트워크의 현재 이벤트 로그가 있지만 중요한 상황에 대한 경고를 보내기 위해 이 체계를 사용할 필요는 없습니다.
표준 센서 외에도 OpManager는 Dell Power-Edge, HP Proliant 및 IBM Blade Center와 같은 장치를 위해 공급업체에서 개발한 SNMP 성능 모니터링 기술을 제공합니다. 또한 OpManager는 Google Maps API와 통합되어 Google 지도에 기기를 추가할 수 있습니다. 그러나 무료 버전의 Google Maps API 시스템에 대한 라이선스 조건에 따라 Google Maps API 프리미엄 계정을 구매해야 합니다(지도를 공개적으로 사용할 계획이 아닌 경우).
관리자가 경고를 수신했지만 지정된 시간 내에 응답하지 않는 상황을 처리하기 위해 다른 관리자에게 추가 경고를 보내도록 OpManager를 구성할 수 있습니다. 예를 들어, 일반적으로 특정 서버 그룹에 대한 중요한 이벤트 처리를 담당하는 직원이 바쁘거나 아플 수 있습니다. 이러한 경우 첫 번째 경고가 지정된 시간/분 내에 확인되지 않거나 지워지지 않으면 다른 관리자의 관심을 끌 추가 경고를 설정하는 것이 좋습니다.
고려 중인 세 가지 제품 중 OpManager 시스템에만 글로벌 네트워크에서 VoIP 교환 품질을 모니터링하도록 설계된 섹션이 있습니다. VoIP 모니터링 도구를 사용하려면 소스 및 대상 네트워크의 장치가 Cisco IP SLA 기술을 지원해야 합니다. 또한 그림 2와 같이 OpManager 시스템에는 경쟁 제품보다 더 많은 센서와 대시보드가 포함되어 있습니다.
.jpg) |
| 그림 2: OpManager 프로페셔널 인터페이스 |
SolarWinds ipMonitor
SolarWinds ipMonitor
당:매우 저렴한 가격에 무제한 장치; 사용의 용이성.
에 맞서:관리자의 작업을 조정하는 메커니즘이 없습니다.
등급: 5개 중 4개.
가격:$ 1995 - 장치 수에는 제한이 없습니다(25개의 센서는 무료).
권장 사항:예산이 빠듯하고 많은 수의 장치를 모니터링해야 하는 경우, 모니터링 프로세스에 복잡한 솔루션이 필요하지 않고 관리자 작업을 조정하는 비체계적인 접근 방식에 익숙한 경우 SolarWinds가 시스템입니다.
연락처 정보: SolarWinds, www.solarwinds.com
ipMonitor를 처음 소개한 후 그림 3의 인터페이스가 혼란스러웠습니다. 개별 시스템 센서에 대한 시스템 검사 빈도가 구성되는 위치를 찾는 데 거의 영원이 걸렸습니다(기본적으로 폴링은 300초마다 수행됨). 그러나 몇 주 동안 ipMonitor를 사용한 후 이 시스템이 사용하기가 매우 쉽고 고품질 네트워크 모니터링을 위한 충분한 기능이 있다는 것을 알게 되었습니다. ipMonitor를 사용하면 모든 서비스 또는 성능 설정이 향후 검사에 항상 포함되도록 기본 검사를 구성할 수 있습니다. 표준(위에서 명명된) 센서 외에도 ipMonitor는 중요한 이벤트가 감지될 때 경고를 보내는 데 사용할 수 있는 Windows 이벤트 로그 센서를 제공합니다.
.jpg) |
| 그림 3 SolarWinds ipMonitor 인터페이스 |
반면에 ipMonitor에는 경고 대상을 추적/할당하는 메커니즘이 없습니다. 회사에 네트워크 관리자가 한 명 있어도 상관없지만 규모가 큰 IT 부서에서는 시스템이 경고를 인식하고 대상을 지정하고 경고를 재설정할 수 없다는 것이 큰 단점임을 알게 될 것입니다. 관리자가 시스템 외부에서 조정하는 것을 잊어버린 경우 여러 관리자가 동일한 경고를 받고 동일한 문제에 대해 작업을 시작할 수 있습니다. 그러나 이러한 충돌을 해결하려면 경고에 응답하기 위한 일관된 알고리즘을 개발하는 것으로 충분합니다. 예를 들어 네트워크 장치에 대한 책임이 관리자 간에 분산되어 있으면 특정 문제를 처리해야 하는 사람에 대한 질문이 없습니다.
결정을 내릴 시간
나는 이미 세 가지 제품 중 내 환경에 더 적합한 제품을 스스로 결정했습니다. 나는 여러 가지 이유로 50개 장치 라이선스로 ManageEngine OpManager로 결정했습니다.
우선, 예상하지 못한 오류를 방지하는 가장 좋은 방법이므로 가능한 한 많은 환경 매개변수를 추적할 수 있어야 합니다. 이 점에서 OpManager 시스템은 확실히 경쟁에서 앞서 있습니다. 두 번째 이유는 예산입니다. 나는 워크스테이션과 프린터를 위한 우리의 오래된 on/off 모니터링 도구를 계속 사용할 수 있고 따라서 추가 라이선스 비용을 피할 수 있습니다. 마지막으로 ManageEngine이 새로운 기술을 활용하기 위해 OpManager를 개발하는 방식이 정말 마음에 들었고, 제품이 개발됨에 따라 업데이트를 다운로드하기 위해 연간 유지 관리 및 지원 패키지를 구입하는 데 투자할 가치가 있다고 생각합니다.
네이트 맥아몬드( [이메일 보호됨]) - 사회 서비스 기관인 MCSE, Security and Network +의 IT 이사, 씬 클라이언트 솔루션 및 의료 데이터베이스 전문
수필
이 문서는 Gerkon LLC의 Verkhnepyshminsk 시 공공 데이터 전송 네트워크를 위한 네트워크 모니터링 시스템의 개발 및 구현을 위한 기술 프로젝트입니다. 이 프로젝트는 기존 네트워크 모니터링 시스템을 조사하고 기업의 현재 상황을 분석하고 네트워크 모니터링 시스템의 특정 구성 요소 선택을 입증했습니다.
이 문서에는 설계 솔루션 및 장비 사양에 대한 설명이 포함되어 있습니다.
설계의 결과는 시스템의 구현 및 사용을 위해 개발된 솔루션입니다.
§ 시스템의 설계, 개발 및 구현의 모든 단계에 대한 전체 설명 § 시스템 사용자 인터페이스에 대한 설명이 포함된 시스템 관리자 안내서. 이 문서는 완전한 설계 솔루션을 제시하며 시스템을 구현하는 데 사용할 수 있습니다. 그래픽 문서 시트 목록 표 1 - 그래픽 문서의 시트 목록 1네트워크 모니터링 시스템220100 4010002네트워크의 논리적 구조220100 4010003네트워크 모니터링 및 경고의 핵심 알고리즘220100 4010004네트워크 인터페이스의 분석기 로드 구조220100100020010 시스템의 이벤트 로그 구조 기호, 기호 및 용어 목록 이더넷은 IEEE에서 발행한 데이터 전송 표준입니다. 공통 데이터 전송 매체에서 데이터를 보내거나 받는 방법을 결정합니다. 하위 전송 계층을 형성하고 다양한 상위 수준 프로토콜에서 사용됩니다. 10Mbps의 데이터 전송 속도를 제공합니다. Fast Ethernet은 10Base-T와 마찬가지로 CSMA/CD 방식을 사용하는 100Mbps 데이터 전송 기술입니다. FDDI - Fiber Distributed Data Interface - 분산 데이터 전송을 위한 광섬유 인터페이스 - 토큰 링 방식을 사용하는 100Mbit/s 속도로 데이터 전송 기술. IEEE - Institute of Electrical and Electronic Engineers는 표준을 개발하고 발표하는 조직입니다. LAN - 근거리 통신망 - 근거리 통신망, LAN. 주소 - 미디어 액세스 제어 - 일반적으로 제조업체에서 결정하는 네트워크 장치의 식별 번호입니다. RFC - 의견 요청 - IEEE 조직에서 발행한 문서 모음으로 표준, 사양 등에 대한 설명을 포함합니다. TCP / IP - 전송 제어 프로토콜 / 인터넷 프로토콜 - 전송 제어 프로토콜 / 인터넷 프로토콜. LAN - 근거리 통신망. OS - 운영 체제. 소프트웨어 - 소프트웨어. SCS - 구조화된 케이블링 시스템. DBMS - 데이터베이스 관리 시스템. 추세 - 소위 추세를 구축할 수 있는 장기 통계입니다. 컴퓨터 - 전자 컴퓨터. 소개 현대 기업의 정보 인프라는 규모가 다른 이종 네트워크와 시스템의 복잡한 집합체입니다. 원활하고 효율적으로 실행하려면 통합 도구가 포함된 엔터프라이즈급 관리 플랫폼이 필요합니다. 그러나 최근까지 네트워크 관리 산업의 구조 자체가 그러한 시스템의 생성을 방해했습니다. 이 시장의 "플레이어"는 다른 공급업체의 시스템과 호환되지 않는 도구와 기술을 사용하여 제한된 범위의 제품을 출시함으로써 주도하려고 했습니다. . 오늘날 상황은 더 나은 방향으로 변하고 있습니다. 데스크탑 시스템에서 메인프레임, LAN에서 인터넷 자원에 이르기까지 다양한 기업 정보 자원을 유연하게 관리할 수 있다고 주장하는 제품이 있습니다. 동시에 제어 애플리케이션은 모든 공급업체의 솔루션에 개방되어야 한다는 인식이 있습니다. 이 작업의 타당성은 개인용 컴퓨터의 보급 및 이를 기반으로 하는 자동화된 워크스테이션(AWS)의 생성과 관련하여 로컬 컴퓨터 네트워크(LAN)의 중요성이 높아졌다는 사실에 기인합니다. 우리 연구의 대상. 연구 주제는 현대 컴퓨터 네트워크를 구성하고 진단하는 주요 방법입니다. "로컬 네트워크 진단"은 정보 네트워크의 상태를 (지속적으로) 분석하는 프로세스입니다. 네트워크 장치가 오작동하는 경우 오작동 사실이 기록되고 그 위치와 유형이 결정됩니다. 오류가 보고되고 장치가 종료되고 백업으로 교체됩니다. 진단 수행에 대한 책임이 가장 많은 네트워크 관리자는 이미 네트워크 형성 단계, 즉 네트워크의 기능을 연구하기 시작해야 합니다. 모든 매개변수와 인터페이스를 나타내는 네트워크 다이어그램과 소프트웨어 구성에 대한 자세한 설명을 알고 있어야 합니다. 이 정보의 등록 및 저장에는 특수 네트워크 문서 시스템이 적합합니다. 이를 사용하여 시스템 관리자는 시스템의 가능한 모든 "숨겨진 결함" 및 "병목 현상"을 미리 파악하여 긴급 상황의 경우 하드웨어 또는 소프트웨어에 문제가 있는지, 프로그램이 손상되거나 오류가 발생하는지 알 수 있습니다. 오류 연산자 작업에. 네트워크 관리자는 사용자의 관점에서 네트워크에 있는 응용 프로그램 소프트웨어의 품질이 결정적이라는 것을 기억해야 합니다. 데이터 전송 오류 수, 네트워크 리소스 활용도, 장비 성능 등과 같은 다른 모든 기준은 부차적입니다. "좋은 네트워크"는 사용자가 작동 방식을 인식하지 못하는 네트워크입니다. 회사 사전 디플로마 실습은 시스템 관리자로서 지원 부서의 Gerkon LLC 기업에서 이루어졌습니다. 이 회사는 1993년부터 이더넷 기술과 전화 접속 채널을 사용하여 Verkhnyaya Pyshma 및 Sredneuralsk 도시에서 인터넷 액세스 서비스를 제공하고 있으며 이 도시에서 최초의 인터넷 서비스 제공업체 중 하나입니다. 서비스 제공에 대한 규칙은 공모 및 규정에 의해 규제됩니다. 사업부의 과학 및 생산 업무 지원 부서는 주어진 기업 내에서 다음과 같은 범위의 작업을 해결합니다. § 전화 접속 및 전용 채널을 통해 인터넷 액세스를 제공하는 기술 및 기술 조직; § 무선 인터넷 액세스의 기술 및 기술 조직; § 사이트(호스팅)의 운영 및 저장을 위한 디스크 공간 할당; § 사서함 또는 가상 메일 서버 지원; § 공급자의 사이트에 클라이언트 장비 배치(코로케이션); § 전용 및 가상 서버 임대 § 데이터 백업; § 민간 기업의 기업 네트워크 배포 및 지원. 1. 네트워크 모니터링 시스템 컴퓨터 네트워크를 감지하고 문제를 해결하기 위한 많은 트릭과 도구에도 불구하고 네트워크 관리자의 기반은 여전히 취약합니다. 컴퓨터 네트워크에는 광섬유 및 무선 구성 요소가 점점 더 많이 포함되어 기존 구리 케이블용으로 설계된 기존 기술과 도구를 사용하는 것이 의미가 없습니다. 또한 100Mbit/s 이상의 속도에서는 전송 매체가 일반 구리 케이블인 경우에도 기존 진단 방식이 실패하는 경우가 많습니다. 그러나 아마도 관리자가 직면해야 하는 컴퓨터 네트워킹의 가장 중요한 변화는 공유 미디어 이더넷에서 개별 서버 또는 워크스테이션이 종종 교환된 세그먼트로 작동하는 교환 네트워크로의 불가피한 전환일 것입니다. 사실, 기술 변환을 구현하면 일부 오래된 문제가 스스로 해결되었습니다. 트위스트 페어 케이블보다 전기 문제를 해결하기가 항상 더 어려웠던 동축 케이블은 기업 환경에서 점점 희귀해지고 있습니다. 주요 문제가 이더넷과의 비유사성(기술적 측면에서 전혀 약점이 아님)인 토큰링 네트워크는 점차적으로 스위치 이더넷 네트워크로 대체되고 있습니다. 네트워크 계층 프로토콜에서 수많은 오류 메시지를 생성하는 SNA, DECnet 및 AppleTalk와 같은 프로토콜은 IP로 대체되고 있습니다. 수백만 명의 고객과 인터넷의 수십억 개의 웹 페이지에서 입증된 바와 같이 IP 스택 자체가 더욱 안정적이고 유지 관리가 쉬워졌습니다. Microsoft의 강력한 적조차도 새 Windows 클라이언트를 인터넷에 연결하는 것이 이전의 타사 TCP/IP 스택과 별도의 전화 접속 소프트웨어를 설치하는 것보다 훨씬 쉽고 안정적이라는 사실을 인정해야 합니다. 많은 최신 기술로 인해 문제를 해결하고 네트워크 성능을 관리하기가 어렵기 때문에 ATM이 PC 수준에서 널리 보급된다면 상황은 더욱 악화될 수 있습니다. 90년대 후반에 100Mbps 대역폭의 토큰링, 100VG-AnyLAN 및 고급 ARCnet 네트워크를 포함하여 여러 다른 고속 데이터 교환 기술이 인정받지 못한 채 거부되었다는 사실도 긍정적인 역할을 했습니다. . 마지막으로 미국은 매우 복잡한 OSI 프로토콜 스택을 거부했습니다(그러나 여러 유럽 정부에서 이를 합법화했습니다). 엔터프라이즈 네트워크 관리자가 직면한 몇 가지 주요 문제를 살펴보겠습니다. 백본 기가비트 이더넷 채널과 개별 클라이언트 시스템을 위한 10 또는 100Mbps의 전용 스위치 포트가 있는 컴퓨터 네트워크의 계층적 토폴로지는 사용자가 잠재적으로 사용할 수 있는 최대 대역폭을 최소 10-20배 증가시켰습니다. 물론 대부분의 컴퓨터 네트워크에는 사용자당 대역폭이 10Mbps보다 훨씬 적기 때문에 서버 또는 액세스 라우터 수준에서 병목 현상이 있습니다. 따라서 10Mbps 허브 포트를 종단 노드용 전용 100Mbps 스위치 포트로 교체한다고 해서 항상 속도가 크게 향상되는 것은 아닙니다. 그러나 최근에 스위치 비용이 감소하고 대부분의 기업이 100Mbps 이더넷 기술을 지원하는 카테고리 5 케이블을 보유하고 있으며 시스템 재부팅 직후 100Mbps로 작동할 수 있는 네트워크 카드가 설치되어 있는 것을 고려하면 현대화의 유혹에 저항하는 것이 왜 그렇게 어려운지 분명합니다. 기존의 공유 미디어 LAN에서 프로토콜 분석기 또는 모니터는 주어진 네트워크 세그먼트의 모든 트래픽을 검사할 수 있습니다. 쌀. 1.1 - 공유 미디어 및 프로토콜 분석기가 있는 기존 LAN 스위치 네트워킹의 성능 이점은 때때로 미묘하지만 스위치 아키텍처의 확산은 기존 진단에 치명적인 결과를 가져왔습니다. 고도로 세분화된 네트워크에서 프로토콜 분석기는 충돌 도메인의 모든 패킷을 조사할 수 있는 레거시 네트워크와 달리 단일 스위치 포트에서만 유니캐스트 트래픽을 볼 수 있습니다. 이러한 조건에서 기존 모니터링 도구는 모든 "대화"에 대한 통계를 수집할 수 없습니다. 끝점의 각 "대화" 쌍이 본질적으로 자체 네트워크를 사용하기 때문입니다. 쌀. 1.2 - 교환 네트워크 스위치 네트워크에서 프로토콜 분석기는 스위치가 동시에 여러 포트를 미러링할 수 없는 경우 한 지점에서 단일 세그먼트만 "볼" 수 있습니다. 고도로 세분화된 네트워크에 대한 제어를 유지하기 위해 스위치 공급업체는 전체 네트워크 "가시성"을 복원하는 다양한 도구를 제공하지만 그 과정에서 많은 문제가 발생합니다. 현재 배송되는 스위치는 일반적으로 포트 미러링을 지원합니다. 이 중 하나의 트래픽은 모니터나 분석기가 연결된 이전에 사용하지 않은 포트로 복제됩니다. 그러나 "미러링"에는 몇 가지 단점이 있습니다. 첫째, 한 번에 하나의 포트만 볼 수 있기 때문에 한 번에 여러 포트에 영향을 미치는 문제를 식별하기가 매우 어렵습니다. 둘째, 미러링은 스위치의 성능을 저하시킬 수 있습니다. 셋째, 미러 포트는 일반적으로 물리적 계층 오류를 재현하지 않으며 때로는 VLAN 지정이 손실되기도 합니다. 마지막으로 많은 경우 전이중 이더넷 링크가 완전히 미러링되지 않을 수 있습니다. 집계된 트래픽 매개변수 분석에 대한 부분적인 솔루션은 특히 대부분의 이더넷 스위치의 모든 포트에 내장되어 있기 때문에 mini-RMON 에이전트의 모니터링 기능을 사용하는 것입니다. 미니 RMON 에이전트는 전체 프로토콜 분석을 제공하는 RMON II 사양 캡처 개체 그룹을 지원하지 않지만 리소스 활용, 오류율 및 멀티캐스트 볼륨에 대한 통찰력을 계속 제공할 수 있습니다. 포트 미러링 기술의 몇 가지 단점은 Shomiti에서 생산하는 것과 같은 "수동 탭"을 설치하여 극복할 수 있습니다. 이 장치는 사전 설치된 Y 커넥터이며 프로토콜 분석기 또는 다른 장치로 실제 신호를 모니터링할 수 있습니다. 다음 실제 문제는 광학 기능의 문제입니다. 컴퓨터 네트워크 관리자는 일반적으로 광 케이블 문제를 해결하기 위해서만 특수 광 네트워크 진단 장비를 사용합니다. 일반적인 기성 SNMP 또는 CLI 기반 장치 관리 소프트웨어는 광 인터페이스가 있는 스위치 및 라우터의 문제를 진단할 수 있습니다. SONET 장치를 진단해야 하는 네트워크 관리자는 거의 없습니다. 광섬유 케이블과 관련하여 가능한 오작동이 발생하는 이유는 구리 케이블의 경우보다 훨씬 적습니다. 광 신호는 한 도체의 신호가 다른 도체의 신호를 유도할 때 발생하는 누화를 일으키지 않습니다. 이 요소는 구리 케이블 진단 장비를 가장 복잡하게 만듭니다. 광케이블은 전자기 노이즈 및 유도 신호에 영향을 받지 않으므로 엘리베이터 모터 및 형광등과 멀리 떨어져 있을 필요가 없습니다. 즉, 이러한 모든 변수를 진단 시나리오에서 제외할 수 있습니다. 주어진 지점에서 신호 강도 또는 광 전력은 실제로 광 네트워크 문제를 해결할 때 측정해야 하는 유일한 변수입니다. 광 채널의 전체 길이를 따라 신호 손실을 결정할 수 있다면 거의 모든 문제를 식별할 수 있습니다. 구리 케이블 테스터를 위한 저렴한 추가 모듈로 광학 측정이 가능합니다. 대규모 광 인프라를 배포 및 유지 관리하는 기업은 광섬유에 대해 구리용 TDR(Time Domain Reflectometer)과 동일한 기능을 수행하는 OTDR(Optical Time Domain Reflecto-meter)을 구입해야 할 수 있습니다. 이 장치는 레이더처럼 작동합니다. 케이블을 통해 펄스 신호를 보내고 반사를 분석하여 도체의 손상이나 기타 이상을 감지한 다음 검사관에게 문제의 원인을 찾아야 할 위치를 알려줍니다. 케이블 커넥터 및 커넥터의 다양한 공급업체가 광섬유 종단 및 팬아웃을 더 쉽게 만들었지만 여전히 특정 수준의 전문 기술이 필요하며 신중한 정책으로 고급 광학 인프라를 갖춘 기업은 직원을 교육해야 합니다. 케이블 네트워크가 아무리 잘 깔려 있어도 예상치 못한 사고로 인해 케이블이 물리적으로 손상될 가능성은 항상 존재합니다. 802.11b WLAN 문제 해결도 문제를 일으킬 수 있습니다. 무선 미디어는 클라이언트 무선 장치의 모든 소유자 간에 공유되기 때문에 진단 자체는 허브 기반 이더넷 네트워크의 경우처럼 간단합니다. Sniffer TechHlogies는 최대 11Mbps의 대역폭으로 이러한 네트워크에 대한 프로토콜 분석 솔루션을 최초로 제공했으며, 이후 대부분의 주요 분석기 공급업체에서 유사한 시스템을 도입했습니다. 유선 연결이 있는 이더넷 허브와 달리 무선 클라이언트 연결의 품질은 안정적이지 않습니다. 모든 지역 전송 옵션에 사용되는 마이크로파 무선 신호는 약하고 때로는 예측할 수 없습니다. 안테나 위치의 작은 변화라도 연결 품질에 심각한 영향을 미칠 수 있습니다. 무선 LAN 액세스 포인트에는 무선 클라이언트를 방문하고 휴대용 분석기로 처리량 및 오류 상태를 모니터링하는 것보다 종종 더 강력한 진단 방법인 장치 관리 콘솔이 장착되어 있습니다. PDA 사용자가 직면하는 데이터 동기화 및 장치 설정 문제는 네트워크 관리자보다 기술 지원 팀과 더 자연스럽게 조정되지만 머지 않은 미래에 이러한 많은 장치가 독립형 보조 장치에서 진화할 것이라고 예측하는 것은 어렵지 않습니다. PC를 보완하기 위해 , 본격적인 네트워크 클라이언트로. 일반적으로 기업 WLAN 운영자는 호환 가능한 인터페이스 카드가 있는 네트워크 범위 내의 모든 사용자가 시스템의 모든 정보 프레임에 액세스할 수 있는 지나치게 개방된 시스템의 배포를 권장하지 않습니다. WEP(Wired Equivalent Privacy) 무선 보안 프로토콜은 사용자 인증, 무결성 보증 및 데이터 암호화를 제공하지만 일반적으로 완벽한 보안으로 인해 네트워크 문제의 근본 원인을 분석하기 어렵습니다. 보안 WEP 네트워크에서 진단 전문가는 정보 자산을 보호하고 시스템에 대한 액세스를 제어하는 키 또는 암호를 알아야 합니다. 모든 패킷을 수신하는 모드로 액세스할 때 프로토콜 분석기는 모든 프레임 헤더를 볼 수 있지만 여기에 포함된 정보는 키가 없으면 의미가 없습니다. 많은 제조업체에서 원격 액세스 VPN이라고 부르는 터널링된 링크를 진단할 때 발생하는 문제는 암호화된 무선 네트워크를 분석할 때 발생하는 문제와 유사합니다. 트래픽이 터널링된 링크를 통과하지 않으면 문제의 원인을 파악하기가 쉽지 않습니다. 이것은 인증 오류, 끝점 중 하나의 고장 또는 공용 인터넷의 정체일 수 있습니다. 프로토콜 분석기를 사용하여 터널링된 트래픽에서 높은 수준의 오류를 감지하려고 하면 데이터 콘텐츠와 애플리케이션, 전송 및 네트워크 계층 헤더가 암호화되기 때문에 에너지 낭비가 됩니다. 일반적으로 기업 네트워크의 보안을 개선하기 위해 취한 조치는 문제 해결 및 성능 문제를 식별하기 어렵게 만드는 경향이 있습니다. 방화벽, 프록시 서버 및 침입 탐지 시스템은 문제의 현지화를 더욱 복잡하게 만들 수 있습니다. 따라서 컴퓨터 네트워크 진단 문제는 관련성이 있으며 궁극적으로 장애 진단은 관리 작업입니다. 대부분의 미션 크리티컬 기업 시스템의 경우 긴 복구 작업이 가능하지 않으므로 유일한 솔루션은 장애가 발생한 직후 필요한 기능을 인수할 수 있는 중복 장치 및 프로세스를 사용하는 것입니다. 일부 기업에서는 기본 장애가 발생할 경우 네트워크에 항상 추가 중복 구성 요소, 즉 n x 2 구성 요소가 있습니다. 여기서 n은 적절한 성능을 제공하는 데 필요한 기본 구성 요소의 수입니다. MTTR(평균 수리 시간)이 충분히 길면 더 많은 중복성이 필요할 수 있습니다. 요점은 문제 해결 시간을 예측하기가 쉽지 않고 예측할 수 없는 복구 기간 동안 상당한 비용이 든다는 것은 관리가 부실하다는 신호라는 것입니다. 덜 중요한 시스템의 경우 이중화가 경제적으로 실행 가능하지 않을 수 있습니다. 이 경우 기업에서 문제 해결 및 진단 프로세스의 속도를 높이기 위해 가장 효율적인 도구(및 교육)에 투자하는 것이 현명합니다. 또한 특정 시스템에 대한 아웃소싱 지원은 기업, 외부 데이터 센터, 애플리케이션 서비스 제공자(ASP) 또는 관리 서비스 제공자에게 아웃소싱할 수 있습니다. 비용 외에도 타사 서비스 사용 결정에 영향을 미치는 가장 중요한 요소는 자체 직원의 능력 수준입니다. 네트워크 관리자는 특정 기능이 특정 기업 작업과 너무 밀접하게 연결되어 있어 제3자가 회사 직원보다 더 나은 성과를 낼 것으로 기대할 수 없는지 결정해야 합니다. 신뢰성이 많이 요구되는 최초의 엔터프라이즈 네트워크가 배치된 직후에 제조업체와 개발자는 "자가 치유 네트워크"라는 개념을 제시했습니다. 현대 네트워크는 확실히 90년대보다 더 안정적이지만 문제가 저절로 해결되기 시작한 것은 아닙니다. 오늘날의 네트워크에서 소프트웨어 및 하드웨어 오류를 제거하려면 여전히 사람의 개입이 필요하며 단기간에 이러한 상황에 큰 변화가 예상되지 않습니다. 진단 방법과 도구는 현재의 관행과 기술에 부합하지만 네트워크 문제 및 성능 부족을 처리하는 데 네트워크 관리자의 시간을 크게 절약할 수 있는 수준에는 아직 도달하지 않았습니다. 1.1 소프트웨어 진단 컴퓨터 네트워크를 진단하기 위한 소프트웨어 도구 중에서 특별한 네트워크 관리 시스템(네트워크 관리 시스템) - 네트워크의 노드 및 통신 장치 상태에 대한 데이터와 네트워크에서 순환하는 트래픽에 대한 데이터를 수집하는 중앙 집중식 소프트웨어 시스템 회로망. 이러한 시스템은 네트워크를 모니터링하고 분석할 뿐만 아니라 자동 또는 반자동 모드에서 네트워크 관리 작업을 수행합니다. 즉, 장치 포트를 활성화 및 비활성화하고 브리지, 스위치 및 라우터의 주소 테이블에서 브리지 매개변수를 변경하는 등의 작업을 수행합니다. 제어 시스템의 예로는 인기 있는 시스템인 HPOpenView, SunNetManager, IBMNetView가 있습니다. 시스템 관리 도구는 관리 시스템과 유사한 기능을 수행하지만 통신 장비와 관련이 있습니다. 그러나 이러한 두 가지 유형의 제어 시스템의 기능 중 일부는 중복될 수 있습니다. 예를 들어 시스템 제어는 네트워크 트래픽에 대한 가장 간단한 분석을 수행할 수 있습니다. 전문가 시스템. 이러한 유형의 시스템은 네트워크의 비정상적인 작동 원인을 식별하고 네트워크를 작동 상태로 만드는 가능한 방법에 대한 인간의 지식을 축적합니다. 전문가 시스템은 종종 네트워크 관리 시스템, 프로토콜 분석기, 네트워크 분석기 등 다양한 네트워크 모니터링 및 분석 도구의 별도 하위 시스템으로 구현됩니다. 전문가 시스템의 가장 간단한 변형은 상황에 맞는 도움말 시스템입니다. 보다 복잡한 전문가 시스템은 인공 지능 요소가 포함된 소위 지식 기반입니다. 이러한 시스템의 예는 Cabletron Spectrum 제어 시스템에 내장된 전문가 시스템입니다. 1.1.1 프로토콜 분석기 새 네트워크를 설계하거나 기존 네트워크를 현대화하는 동안 네트워크 통신 회선을 통한 데이터 흐름의 강도, 패킷 처리의 다양한 단계에서 발생하는 지연, 요청에 대한 응답 시간과 같은 네트워크의 일부 특성을 정량화해야 하는 경우가 많습니다. 한 가지 유형 또는 다른 유형, 발생 빈도 특정 이벤트 및 기타 특성. 이러한 목적을 위해 다양한 수단이 사용될 수 있으며, 무엇보다도 앞서 이미 논의한 네트워크 관리 시스템의 모니터링 수단이 사용될 수 있습니다. 네트워크의 일부 측정은 운영 체제에 내장된 소프트웨어 측정기로도 수행할 수 있으며, 그 예로 Windows 성능 모니터 구성 요소가 있습니다. 최신 케이블 테스터도 패킷을 캡처하고 내용을 분석할 수 있습니다. 그러나 가장 진보된 네트워크 탐색 도구는 프로토콜 분석기입니다. 프로토콜 분석 프로세스에는 특정 네트워크 프로토콜을 구현하는 네트워크에서 순환하는 패킷을 캡처하고 검사하는 작업이 포함됩니다. 분석 결과를 기반으로 모든 네트워크 구성 요소에 대해 정보에 입각한 균형 잡힌 변경을 수행하고 성능을 최적화하고 문제를 해결할 수 있습니다. 분명히, 네트워크에 대한 일부 변경의 영향에 대한 결론을 도출할 수 있으려면 변경 전후의 프로토콜을 분석해야 합니다. 프로토콜 분석기는 특수 네트워크 카드와 적절한 소프트웨어가 장착된 Нtebook 등급의 독립적인 특수 장치 또는 개인용 컴퓨터(보통 휴대형)입니다. 사용된 네트워크 카드 및 소프트웨어는 네트워크 토폴로지(링, 버스, 스타)와 일치해야 합니다. 분석기는 일반 노드와 동일한 방식으로 네트워크에 연결합니다. 차이점은 분석기는 네트워크를 통해 전송된 모든 데이터 패킷을 수신할 수 있는 반면 일반 스테이션은 주소가 지정된 패킷만 수신할 수 있다는 것입니다. 분석기 소프트웨어는 네트워크 어댑터의 작동을 지원하고 수신된 데이터를 디코딩하는 커널과 조사 중인 네트워크의 토폴로지 유형에 따라 달라지는 추가 프로그램 코드로 구성됩니다. 또한 IPX와 같은 다양한 프로토콜별 디코딩 루틴이 제공됩니다. 일부 분석기에는 주어진 상황에서 어떤 실험을 수행해야 하는지, 이러한 측정 결과가 의미하는 바, 일부 유형의 네트워크 오작동을 제거하는 방법에 대한 사용자 권장 사항을 제공할 수 있는 전문가 시스템도 포함될 수 있습니다. 시장에 나와 있는 프로토콜 분석기의 상대적 다양성에도 불구하고, 이들 모두에 다소 고유한 몇 가지 기능이 있습니다. 사용자 인터페이스. 대부분의 분석기는 일반적으로 Windows 또는 Motif를 기반으로 잘 개발된 사용자 친화적인 인터페이스를 가지고 있습니다. 이 인터페이스를 통해 사용자는 다음을 수행할 수 있습니다. 트래픽 강도 분석 결과를 표시합니다. 네트워크 성능에 대한 즉각적이고 평균적인 통계 추정치를 얻습니다. 특정 이벤트 및 중요한 상황을 설정하여 발생을 추적합니다. 다양한 수준의 프로토콜을 디코딩하고 패킷의 내용을 이해할 수 있는 형식으로 표시합니다. 캡처 버퍼. 다양한 분석기의 버퍼는 크기가 다릅니다. 버퍼는 설치된 네트워크 카드에 있거나 네트워크에 있는 컴퓨터 중 하나의 RAM 공간에 할당될 수 있습니다. 버퍼가 네트워크 카드에 있으면 하드웨어에서 관리하므로 입력 속도가 빨라집니다. 그러나 이는 분석기 비용의 증가로 이어집니다. 캡처 절차의 수행이 불충분할 경우 일부 정보가 손실되고 분석이 불가능합니다. 버퍼 크기는 캡처된 데이터의 대표 샘플에 대한 분석 기능을 결정합니다. 그러나 캡처 버퍼가 아무리 크더라도 조만간 가득 찰 것입니다. 이 경우 캡처가 중지되거나 버퍼의 시작 부분에서 채우기가 시작됩니다. 필터. 필터를 사용하면 데이터 캡처 프로세스를 제어할 수 있으므로 버퍼 공간을 절약할 수 있습니다. 필터 조건으로 지정된 패킷의 특정 필드 값에 따라 패킷이 무시되거나 캡처 버퍼에 기록됩니다. 필터를 사용하면 현재 필요하지 않은 패키지를 볼 수 없기 때문에 분석 속도가 크게 빨라지고 단순화됩니다. 스위치는 네트워크에서 데이터를 캡처하는 프로세스를 시작 및 중지하기 위해 운영자가 설정한 몇 가지 조건입니다. 이러한 조건은 캡처 프로세스를 시작 및 중지하는 수동 명령 실행, 시간, 캡처 프로세스 기간, 데이터 프레임의 특정 값 표시일 수 있습니다. 스위치는 필터와 함께 사용할 수 있어 보다 상세하고 미묘한 분석이 가능하고 제한된 크기의 캡처 버퍼를 보다 생산적으로 사용할 수 있습니다. 찾다. 일부 프로토콜 분석기를 사용하면 버퍼의 정보 보기를 자동화하고 지정된 기준에 따라 버퍼에서 데이터를 찾을 수 있습니다. 필터가 필터링 조건에 대해 입력 스트림을 확인하는 동안 검색 기능은 버퍼에 이미 축적된 데이터에 적용됩니다. 분석 방법론은 다음 6단계로 제시할 수 있습니다. 데이터 캡처. 캡처된 데이터를 봅니다. 데이터 분석. 오류를 검색합니다. (대부분의 분석기는 오류 유형을 식별하고 오류 패킷이 발생한 스테이션을 식별하여 이를 더 쉽게 만듭니다.) 성능 연구. 네트워크 대역폭의 사용률 또는 요청에 대한 평균 응답 시간이 계산됩니다. 네트워크의 개별 섹션에 대한 자세한 연구. 이 단계의 내용은 분석이 수행되면서 구체화됩니다. 일반적으로 프로토콜 분석 프로세스는 영업일 기준 1-2일이라는 비교적 짧은 시간이 소요됩니다. 대부분의 최신 분석기를 사용하면 X.25, PPP, SLIP, SDLC/SNA, 프레임 릴레이, SMDS, ISDN, 브리지/라우터 프로토콜(3Com, Cisco, Bay Networks 등)과 같은 여러 WAN 프로토콜을 한 번에 분석할 수 있습니다. 이러한 분석기를 사용하면 프로토콜의 다양한 매개변수를 측정하고, 네트워크 트래픽을 분석하고, LAN과 WAN 프로토콜 간의 변환, 이러한 변환 중 라우터의 지연 등을 수행할 수 있습니다. 고급 장치는 WAN 프로토콜, "스트레스" 테스트, 측정을 시뮬레이션 및 디코딩하는 기능을 제공합니다. 최대 대역폭, 제공되는 서비스 품질 테스트. 다양성을 위해 거의 모든 WAN 프로토콜 분석기는 LAN 테스트와 모든 주요 인터페이스를 구현합니다. 일부 기기는 전화 통신 프로토콜을 분석할 수 있습니다. 그리고 가장 진보된 모델은 7개의 OSI 레이어를 모두 디코딩하고 편리하게 표현할 수 있습니다. ATM의 출현으로 제조업체는 분석기에 이러한 네트워크용 테스트 도구를 공급하게 되었습니다. 이 장비는 모니터링 및 시뮬레이션 지원을 통해 E-1 / E-3 ATM 네트워크의 완전한 테스트를 수행할 수 있습니다. 분석기의 서비스 기능 세트는 매우 중요합니다. 예를 들어 장치를 원격으로 제어하는 기능과 같은 일부 기능은 대체할 수 없습니다. 따라서 WAN/LAN/DTM 프로토콜의 최신 분석기는 라우터 및 브리지 구성에서 오류를 감지할 수 있습니다. WAN을 통해 전송되는 트래픽 유형을 설정합니다. 사용된 속도 범위를 결정하고 대역폭과 채널 수 간의 비율을 최적화합니다. 잘못된 트래픽의 소스를 현지화합니다. 직렬 인터페이스 테스트 및 전체 ATM 테스트 수행 모든 채널에서 주요 프로토콜의 전체 모니터링 및 디코딩을 수행합니다. 글로벌 네트워크 전반의 근거리 통신망 트래픽 분석을 포함하여 실시간으로 통계를 분석합니다. 1.1.2 모니터링 프로토콜 SNMP(Simple Network Management Protocol)는 TCP/IP 아키텍처를 기반으로 하는 통신 네트워크 관리 프로토콜입니다. 1980-1990년 TMN 개념을 기반으로 다양한 표준화 기관에서 다양한 스펙트럼의 TMN 기능 구현을 통해 데이터 네트워크를 관리하기 위한 여러 프로토콜을 개발했습니다. 이러한 관리 프로토콜의 한 유형은 SNMP입니다. SNMP는 네트워크 라우터 및 브리지의 기능을 테스트하기 위해 개발되었습니다. 그 후 프로토콜의 범위는 허브, 게이트웨이, 터미널 서버, LAN Manager 서버, Windows NT 시스템 등과 같은 다른 네트워크 장치로 확장되었습니다. 또한 프로토콜을 통해 이러한 장치의 기능을 변경할 수 있습니다. 이 기술은 네트워크 장치에 있는 에이전트와 제어 스테이션에 있는 관리자 간에 제어 정보를 교환하여 통신 네트워크의 장치 및 응용 프로그램에 대한 관리 및 제어를 제공하도록 설계되었습니다. SNMP는 네트워크를 네트워크 관리 스테이션과 네트워크 에이전트 간의 관리 링크를 집합적으로 제공하는 네트워크 관리 스테이션 및 네트워크 요소(호스트, 게이트웨이 및 라우터, 터미널 서버)의 모음으로 정의합니다. SNMP에는 관리 및 감독되는 시스템이 있습니다. 관리되는 시스템에는 관리 시스템에 보고서를 보내는 에이전트라는 구성 요소가 포함됩니다. 기본적으로 SNMP 에이전트는 관리 정보를 변수(예: "사용 가능한 메모리", "시스템 이름", "실행 중인 프로세스 수")로 관리 시스템에 전송합니다. SNMP 에이전트는 네트워크의 관리 스테이션에 위치한 관리자에게 MIB 변수 값에 대한 액세스 권한을 제공하여 장치 관리 및 모니터링 기능을 구현할 수 있도록 하는 처리 요소입니다. 소프트웨어 에이전트는 관리 기능을 수행하고 이를 네트워크 장치의 정보 기반으로 전송하기 위한 통계를 수집하는 상주 프로그램입니다. 하드웨어 에이전트 - 소프트웨어 에이전트를 저장하는 임베디드 하드웨어(프로세서 및 메모리 포함). SNMP를 통해 액세스할 수 있는 변수는 계층 구조로 구성됩니다. 이러한 계층 구조 및 기타 메타데이터(예: 변수 유형 및 설명)는 MIB(관리 정보 기반)에서 설명합니다. 오늘날 제어 정보 데이터베이스에 대한 몇 가지 표준이 있습니다. 주요 표준은 MIB-I 및 MIB-II 표준과 원격 관리를 위한 데이터베이스의 RMON MIB 버전입니다. 또한 특정 유형의 특정 장치 MIB에 대한 표준(예: 허브용 MIB 또는 모뎀용 MIB)과 특정 장비 제조업체의 독점 MIB에 대한 표준이 있습니다. 원래 MIB-I 사양은 변수 값에 대한 읽기 작업만 정의했습니다. 객체의 값을 변경하거나 설정하는 작업은 MIB-II 사양의 일부입니다. MIB-I 버전(RFC 1156)은 8개의 그룹으로 분류되는 최대 114개의 객체를 정의합니다. 시스템 - 장치에 대한 일반 정보(예: 공급업체 ID, 마지막 시스템 초기화 시간). 인터페이스 - 장치의 네트워크 인터페이스 매개변수(예: 번호, 유형, 환율, 최대 패킷 크기)를 설명합니다. AddressTranslationTable - 네트워크와 물리적 주소 간의 대응 관계를 설명합니다(예: ARP 프로토콜 사용). InternetProtocol - IP 프로토콜과 관련된 데이터(IP 게이트웨이 주소, 호스트, IP 패킷에 대한 통계). ICMP - ICMP 제어 메시지 교환 프로토콜과 관련된 데이터입니다. TCP - TCP 프로토콜과 관련된 데이터(예: TCP 연결 정보). UDP - UDP 프로토콜과 관련된 데이터(전송, 수신 및 잘못된 UPD 데이터그램 수). EGP - 인터넷에서 사용되는 ExteriorGatewayProtocol 라우팅 교환 프로토콜과 관련된 데이터(오류가 있거나 없는 수신된 메시지 수). 이 변수 그룹 목록에서 MIB-I 표준은 TCP/IP 스택 프로토콜을 지원하는 라우터 관리에 엄격한 초점을 두고 개발되었음을 알 수 있습니다. 1992년에 채택된 MIB-II 버전(RFC 1213)에서는 표준 개체 집합이 185개로 크게 확장되었고 그룹 수도 10개로 늘어났습니다. RMON 에이전트 SNMP 기능에 대한 최신 추가 기능은 MIB와의 원격 통신을 제공하는 RMON 사양입니다. RMON 표준은 Internet Engineering Task Force가 "Remote Network Monitoring Management Information Base"라는 제목의 RFC 1271을 발행한 1991년 11월에 등장했습니다. 이 문서에는 이더넷 네트워크용 RMON에 대한 설명이 포함되어 있습니다. - 컴퓨터 네트워크 모니터링 프로토콜인 SNMP 확장은 SNMP와 마찬가지로 네트워크를 통해 전송되는 정보의 특성에 대한 정보 수집 및 분석을 기반으로 합니다. SNMP에서와 같이 정보 수집은 하드웨어 및 소프트웨어 에이전트에 의해 수행되며, 이로부터 데이터는 네트워크 관리 응용 프로그램이 설치된 컴퓨터로 전송됩니다. RMON과 이전 버전의 차이점은 무엇보다도 수집된 정보의 특성에 있습니다. SNMP에서 이 정보가 에이전트가 설치된 장치에서 발생하는 이벤트만 특성화하는 경우 RMON은 네트워크 간의 트래픽 특성화를 위해 수신된 데이터를 요구합니다. 장치. RMON 이전에는 SNMP를 원격으로 사용할 수 없었고 장치의 로컬 관리만 허용했습니다. RMON MIB에는 네트워크를 통해 많은 양의 정보를 전송할 필요가 없는 장치에 대한 집계 정보가 포함되어 있으므로 원격 관리를 위한 향상된 속성 집합이 있습니다. RMON MIB 개체에는 추가 패킷 오류 카운터, 보다 유연한 그래픽 추세 및 통계 분석, 개별 패킷 캡처 및 분석을 위한 보다 강력한 필터링 도구, 보다 복잡한 경보 조건이 포함됩니다. RMON MIB 에이전트는 MIB-I 또는 MIB-II 에이전트보다 더 지능적이며 관리자가 하던 대부분의 장치 정보 처리 작업을 수행합니다. 이러한 에이전트는 다양한 통신 장치 내부에 위치할 수 있으며 범용 PC 및 랩톱에서 실행되는 별도의 소프트웨어 모듈 형태로 실행될 수도 있습니다(예: LANalyzerНvell). RMON 에이전트의 인텔리전스를 통해 오류를 진단하고 가능한 오류에 대해 경고하는 간단한 작업을 수행할 수 있습니다. 예를 들어, RMON 기술을 사용하여 네트워크의 정상적인 기능에 대한 데이터를 수집할 수 있습니다(즉, 소위 기준 설정 수행). 그런 다음 네트워크 작동 모드가 기준선에서 벗어날 때 경고를 발행합니다. 이는 특히 장비가 완전히 작동하지 않는다는 것을 나타낼 수 있습니다. 관리 응용 프로그램은 RMON 에이전트의 정보를 취합하여 네트워크 관리자(예: 분석된 네트워크 세그먼트에서 수천 킬로미터에 위치)가 문제를 파악하고 문제를 해결하기 위한 최적의 조치 계획을 개발하는 데 도움을 줄 수 있습니다. RMON 정보 수집은 네트워크에 직접 연결된 하드웨어 및 소프트웨어 프로브에 의해 수행됩니다. 데이터 수집 및 기본 분석 작업을 수행하려면 프로브에 충분한 컴퓨팅 리소스와 RAM 양이 있어야 합니다. 현재 시장에는 세 가지 유형의 프로브가 있습니다: 임베디드, 컴퓨터 기반 및 독립 실행형. 제품이 하나 이상의 RMON 그룹을 구현하는 경우 RMON 가능 제품으로 간주됩니다. 물론, 주어진 제품에 더 많은 RMON 데이터 그룹이 구현될수록, 한편으로는 더 비싸고, 다른 한편으로는 그것이 제공하는 네트워크 운영에 대한 더 완전한 정보를 제공합니다. 내장형 프로브는 네트워크 장치용 확장 모듈입니다. 이러한 모듈은 3Com, Cabletron, Bay Networks 및 Cisco와 같은 주요 회사를 비롯한 많은 제조업체에서 사용할 수 있습니다. (참고로, 3Com과 Bay Networks는 최근 RMON 컨트롤의 설계 및 제조 분야에서 유명한 리더인 Axon과 ARMON을 인수했습니다. 주요 네트워크 장비 제조업체의 이 기술에 대한 관심은 사용자에게 얼마나 많은 원격 모니터링이 필요한지 더 잘 보여줍니다.) 허브에 있는 RMON 모듈은 자연스럽게 보입니다. 왜냐하면 이러한 장치를 관찰함으로써 세그먼트의 작동에 대한 아이디어를 형성할 수 있기 때문입니다. 이러한 프로브의 장점은 분명합니다. 모든 주요 RMON 데이터 그룹에 대한 정보를 비교적 저렴한 가격에 얻을 수 있다는 것입니다. 무엇보다 단점은 성능이 그리 높지 않다는 것입니다. 특히 내장형 프로브가 모든 RMON 데이터 그룹을 지원하지 않는 경우가 많다는 점에서 더욱 그렇습니다. 3Com은 최근 Etherlink III 및 Fast Ethernet 네트워크 어댑터용 RMON 지원 드라이버를 출시할 계획이라고 발표했습니다. 결과적으로 네트워크의 워크스테이션에서 직접 RMON 데이터를 수집하고 분석할 수 있습니다. 컴퓨터 기반 프로브는 단순히 RMON 소프트웨어 에이전트가 설치된 네트워크 컴퓨터입니다. 이러한 프로브(예: Network General의 Cornerstone Agent 2.5 포함)는 기본 제공 프로브보다 더 나은 성능을 제공하고 일반적으로 모든 RMON 데이터 세트를 지원합니다. 내장형 프로브보다 비싸지만 독립형 프로브보다 훨씬 저렴합니다. 또한 컴퓨터 기반 프로브는 상당히 커서 때때로 적용 가능성이 제한될 수 있습니다. 독립형 프로브가 최고의 성능을 발휘합니다. 이해하기 쉽기 때문에 이들은 동시에 설명된 모든 제품 중 가장 비싼 제품입니다. 일반적으로 독립형 프로브는 충분한 RAM과 네트워크 어댑터가 장착된 프로세서(i486 클래스 또는 RISC 프로세서)입니다. 이 부문의 시장 리더는 Frontier와 Hewlett-Packard입니다. 이 유형의 프로브는 크기가 작고 이동성이 매우 높아 네트워크에 연결하고 연결 해제하기가 매우 쉽습니다. 글로벌 규모의 네트워크를 관리하는 문제를 해결할 때 이것은 물론 그다지 중요한 속성은 아니지만 RMON 도구를 사용하여 중소 기업 네트워크의 운영을 분석하는 경우 (높은 비용을 감안할 때 장치) 프로브의 이동성은 매우 긍정적인 역할을 할 수 있습니다. RMON 개체는 MIB 개체 집합에서 16번으로 지정되며 RMON 개체 자체는 RFC 1271에 따라 번들로 제공되며 10개의 데이터 그룹으로 구성됩니다. 통계 - 패킷 특성, 충돌 횟수 등에 대한 현재 누적 통계 기록 - 변경 추세의 후속 분석을 위해 정기적으로 저장된 통계 데이터입니다. 경보 - RMON 에이전트가 관리자에게 메시지를 보내는 통계 임계값입니다. 사용자가 여러 임계값 수준을 정의할 수 있습니다(이 임계값은 통계 그룹의 매개변수, 진폭 또는 변화율 등 다양한 항목을 참조할 수 있음). 초과 시 경보가 생성됩니다. 사용자는 어떤 조건에서 임계값을 초과하면 경보 신호가 수반되어야 하는지 결정할 수 있습니다. 이렇게 하면 첫째로 아무도 지속적으로 불타는 붉은 빛에 주의를 기울이지 않기 때문에 나쁜 "아무도 없는" 신호 생성을 피할 수 있습니다. , 그리고 두 번째로 네트워크를 통한 불필요한 경보의 전송은 통신 회선의 불필요한 혼잡을 초래하기 때문입니다. 알람은 일반적으로 이벤트 그룹으로 전달되어 다음에 수행할 작업이 결정됩니다. 호스트 - MAC 주소를 포함하여 네트워크의 호스트에 대한 데이터 .. HostTopN은 네트워크에서 가장 바쁜 호스트의 테이블입니다. 호스트 N 호스트 테이블(HostTopN)에는 지정된 간격 동안 지정된 통계의 가장 높은 값을 가진 상위 N 호스트 목록이 포함됩니다. 예를 들어, 지난 24시간 동안 최대 오류 수를 경험한 10개의 호스트 목록을 요청할 수 있습니다. 이 목록은 에이전트 자체에 의해 컴파일되며 관리 응용 프로그램은 이러한 호스트의 주소와 해당 통계 매개변수의 값만 수신합니다. 이 접근 방식이 네트워크 리소스를 어느 정도 절약하는지 알 수 있습니다. TrafficMatrix - 네트워크의 각 호스트 쌍 간의 트래픽 강도에 대한 통계로, 매트릭스로 정렬됩니다. 이 행렬의 행은 스테이션의 MAC 주소(메시지 소스 및 열)에 따라 번호가 매겨지며 수신자 스테이션의 주소에 따라 지정됩니다. Matrix 요소는 각 스테이션 간의 트래픽 강도와 오류 수를 특성화합니다. 이러한 매트릭스를 분석하면 사용자는 가장 집중적인 트래픽을 생성하는 스테이션 쌍을 쉽게 찾을 수 있습니다. 이 매트릭스는 다시 에이전트 자체에 의해 형성되므로 네트워크 관리를 담당하는 중앙 컴퓨터에 많은 양의 데이터를 전송할 필요가 없습니다. 필터 - 패킷 필터링 조건. 패킷을 필터링하는 기준은 매우 다양할 수 있습니다. 예를 들어 길이가 지정된 특정 값보다 작은 모든 패킷을 잘못된 패킷으로 필터링하도록 요구할 수 있습니다. 필터의 설치는 말하자면 패킷을 전송하는 채널의 구성에 해당한다고 말할 수 있습니다. 이 채널이 리드하는 위치는 사용자가 결정합니다. 예를 들어 모든 잘못된 패킷을 가로채서 적절한 버퍼로 보낼 수 있습니다. 또한, 설정된 필터와 일치하는 패킷의 출현은 시스템이 미리 정해진 방식으로 반응해야 하는 이벤트로 볼 수 있다. PacketCapture - 패킷 캡처를 위한 조건입니다. 패킷 캡처 그룹에는 필터 그룹에 명시된 조건을 충족하는 특성을 가진 패킷이 전송되는 캡처 버퍼가 포함됩니다. 이 경우 전체 패킷이 캡처되지 않고 패킷의 처음 수십 바이트만 캡처될 수 있습니다. 가로채기 버퍼의 내용은 이후에 다양한 소프트웨어 도구를 사용하여 분석되어 네트워크의 매우 유용한 여러 특성을 드러낼 수 있습니다. 특정 기호에 대한 필터를 재배열하여 네트워크 작동의 다양한 매개변수를 특성화할 수 있습니다. 이벤트 - 이벤트를 등록하고 생성하기 위한 조건입니다. 이벤트 그룹은 관리 애플리케이션에 경보를 보낼 때, 패킷을 가로챌 때, 그리고 일반적으로 네트워크에서 발생하는 특정 이벤트에 응답하는 방법을 정의합니다(예: 경보 그룹에 설정된 임계값이 초과된 경우): 설정 여부 제어 응용 프로그램이 알림을 받거나 이 이벤트를 기록하고 작업을 계속하기만 하면 됩니다. 이벤트는 알람 전송과 관련되거나 관련되지 않을 수 있습니다. 예를 들어 캡처 버퍼로 패킷을 보내는 것도 이벤트입니다. 이러한 그룹에는 표시된 순서대로 번호가 지정되므로 예를 들어 Hosts 그룹의 숫자 이름은 1.3.6.1.2.1.16.4입니다. 열 번째 그룹은 TokenRing 프로토콜의 특수 개체로 구성됩니다. 전체적으로 RMON MIB 표준은 이더넷 네트워크용 RFC 1271 및 TokenRing 네트워크용 RFC 1513의 두 문서에 기록된 10개 그룹의 약 200개 개체를 정의합니다. RMON MIB 표준의 독특한 특징은 네트워크 계층 프로토콜과의 독립성입니다(TCP/IP 프로토콜을 지향하는 MIB-I 및 MIB-II 표준과 대조적으로). 따라서 서로 다른 네트워크 계층 프로토콜을 사용하는 이기종 환경에서 사용하는 것이 편리합니다. 1.2 대중적인 네트워크 관리 시스템 네트워크 관리 시스템 - 네트워크 노드를 모니터링하고 관리하기 위한 하드웨어 및/또는 소프트웨어 도구. 네트워크 관리 시스템 소프트웨어는 네트워크 장치에 국한되고 네트워크 관리 플랫폼에 정보를 전송하는 에이전트로 구성됩니다. 관리 응용 프로그램과 장치의 에이전트 간의 통신 방법은 프로토콜에 의해 결정됩니다. 네트워크 관리 시스템에는 다음과 같은 여러 품질이 있어야 합니다. 클라이언트/서버 개념에 따른 진정한 분배, 확장성, 데스크탑에서 메인프레임에 이르기까지 다양한 하드웨어에 대처할 수 있는 개방성. 처음 두 속성은 밀접하게 관련되어 있습니다. 분산 제어 시스템으로 인해 우수한 확장성이 달성됩니다. 분산은 시스템이 여러 서버와 클라이언트를 포함할 수 있음을 의미합니다. 서버(관리자)는 네트워크 장비에 내장된 에이전트(SNMP, CMIP 또는 RMON)로부터 네트워크의 현재 상태에 대한 데이터를 수집하여 데이터베이스에 축적합니다. 클라이언트는 네트워크 관리자가 실행하는 그래픽 콘솔입니다. 관리 시스템 클라이언트 소프트웨어는 관리자의 작업 수행 요청을 수락하고(예: 네트워크 일부에 대한 상세 맵 작성) 서버에 필요한 정보를 요청합니다. 서버에 필요한 정보가 있으면 즉시 클라이언트에 전송하고, 없으면 에이전트로부터 수집을 시도합니다. 초기 버전의 제어 시스템은 관리자가 실행하는 하나의 컴퓨터에 모든 기능을 결합했습니다. 소규모 네트워크나 제어되는 장비가 적은 네트워크의 경우 이러한 구조는 상당히 만족스러운 것으로 판명되지만 제어되는 장비의 양이 많으면 네트워크의 모든 장치에서 정보가 흐르는 유일한 컴퓨터가 병목 현상이 됩니다. 그리고 네트워크는 대용량 데이터 흐름에 대처할 수 없으며 컴퓨터 자체는 이를 처리할 시간이 없습니다. 또한 대규모 네트워크는 일반적으로 한 명 이상의 관리자가 관리하므로 대규모 네트워크의 여러 서버 외에도 네트워크 관리자를 위한 여러 콘솔이 있어야 하며 각 콘솔은 현재 요구 사항에 해당하는 특정 정보를 제공해야 합니다. 특정 관리자. 이기종 장비에 대한 지원은 오늘날 제어 시스템의 실제 기능보다 바람직합니다. 가장 인기 있는 네트워크 관리 제품에는 4개의 시스템이 있습니다. CabletronSystems의 Spectrum, Hewlett-Packard의 OpenView, IBM의 NetView, SunMicrosystems의 한 부문인 SunSoft의 Solstice입니다. 4개 기업 중 3개 기업은 통신 장비를 자체 생산합니다. 당연히 Spectrum은 Cabletron 장비를 가장 잘 관리하고 OpenView는 Hewlett-Packard 장비를, NetView는 IBM 장비를 관리합니다. 다른 제조사의 장비로 구성된 네트워크 맵을 구축할 때 이러한 시스템은 실수를 하기 시작하여 일부 장비를 다른 장비로 대체하게 되며, 이러한 장비를 관리할 때는 기본 기능만 지원하며 이 장비를 다른 장비와 구별하는 유용한 추가 기능을 많이 지원합니다. 나머지는 제어 시스템이 단순하여 이해하지 못하므로 사용할 수 없습니다. 이러한 결함을 해결하기 위해 관리 시스템 개발자는 표준 MIB I, MIB II 및 RMON MIB뿐만 아니라 제조업체의 수많은 독점 MIB에 대한 지원을 포함합니다. 이 분야의 리더는 다양한 제조업체의 약 1000 MIB를 지원하는 Spectrum 시스템입니다. 특정 하드웨어를 더 잘 지원하는 또 다른 방법은 이 하드웨어를 생산하는 회사의 제어 플랫폼을 기반으로 하는 응용 프로그램을 사용하는 것입니다. 통신 장비 제조업체인 선도 기업은 장비를 위한 고도로 정교하고 다기능적인 제어 시스템을 개발 및 공급해 왔습니다. 이 클래스의 가장 유명한 시스템에는 BayNetworks의 Optivity, CiscoSystems의 CiscoWorks, 3Com의 Transcend가 있습니다. 예를 들어 Optivity를 사용하면 기능과 기능을 최대한 활용하여 BayNetwork에서 라우터, 스위치 및 허브의 네트워크를 모니터링하고 관리할 수 있습니다. 다른 제조사의 장비는 기본 제어 기능 수준으로 유지됩니다. Optivity는 Hewlett-Packard의 OpenView 및 SunSoft의 SunNetManager(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 인터페이스를 사용하여 원격으로 제어할 수 있다는 것입니다. "부모" 호스트의 개념을 사용하여 모든 호스트 간의 계층 및 종속성을 쉽게 설명할 수 있습니다. 이 접근 방식은 복잡한 진단을 허용하기 때문에 대규모 네트워크에 매우 유용합니다. 그리고 이 품질은 중간 링크 작동의 오작동으로 인해 작동하지 않는 호스트와 현재 사용할 수 없는 호스트를 구별하는 데 도움이 됩니다. Nagios는 모니터링되는 시스템의 그래프와 모니터링되는 네트워크 인프라의 맵을 구축할 수 있습니다. 저자는 Nagios와 함께 작업한 경험에서 그가 개인 작업에서 얼마나 유용했는지 보여주는 예를 들 수 있습니다. 몇 시간 간격으로 방화벽의 외부 네트워크 인터페이스에서 패킷 손실이 시작되었습니다. 오작동으로 인해 통행 차량의 최대 20%가 손실되었습니다. 1분 후 다른 인터페이스가 예상대로 다시 작동하기 시작했습니다. 이 문제의 플로팅 특성으로 인해 인터넷 사용 시 간헐적인 중단이 발생하는 이유를 몇 주 동안 파악할 수 없었습니다. Nagios가 없으면 문제 해결에 오랜 시간이 걸립니다. 많은 관리자가 Nagios의 조상 NetSaint에 대해 잘 알고 있습니다. NetSaint 프로젝트 사이트는 아직 가동 중이지만 새로운 개발은 Nagios 소스 코드를 기반으로 합니다. 따라서 모두 천천히 Nagios로 이동하는 것이 좋습니다. Nagios와 함께 제공되는 문서에는 다른 많은 Unix 계열 시스템에서 안정적으로 작동한다고 나와 있습니다. Nagios 웹 인터페이스를 표시하려면 Apache 서버가 필요합니다. 다른 것을 자유롭게 사용할 수 있지만 이 작업에서는 Apache를 Unix 플랫폼에서 가장 널리 사용되는 웹 서버로 간주합니다. 웹 인터페이스 없이 모니터링 시스템을 설치하는 것은 전혀 가능하지만 사용성을 크게 떨어뜨리므로 하지 않습니다. 4. 소프트웨어 개발 구현되는 시스템의 하드웨어 부분으로 일반 IBM 호환 컴퓨터를 사용할 수 있지만 안정성 및 MTBF의 부하 및 요구 사항이 추가로 증가할 가능성을 고려하고 Aquarius의 인증된 서버 장비인 GosvyazNadzor는 구입 한. 기존 네트워크는 Linux 커널 기반의 데비안 운영 체제를 적극적으로 사용하고 이 시스템을 사용한 광범위한 경험이 있으며 대부분의 작업을 디버깅하여 관리, 구성 및 안정성을 보장합니다. 또한 이 OS는 GPL 라이선스에 따라 배포되므로 네트워크 모니터링 시스템 설계에 대한 업데이트된 참조 조건에 해당하는 무료 및 오픈 소스입니다.(전체 이름 GNU/Linux, "gnu slash" 발음) 하다 ́ nux ", 일부 언어에서도 " GNU + Linux "," GNU-Linux " 등)는 같은 이름의 커널과 이를 위해 컴파일된 라이브러리 및 시스템 프로그램을 기반으로 하는 UNIX 계열 운영 체제의 일반 이름입니다. GNU 프로젝트의 프레임워크 내에서./ Linux는 Intel x86 제품군의 PC 호환 시스템과 IA-64, AMD64, PowerPC, ARM 및 기타 여러 시스템에서 실행됩니다. GNU/리눅스 운영 체제는 종종 이 운영 체제를 보완하는 프로그램, 그리고 이를 본격적인 다기능 운영 환경으로 만드는 응용 프로그램이라고도 합니다. 대부분의 다른 운영 체제와 달리 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와 호환되지만 자체 소스 코드를 기반으로 합니다. [출처 불특정 199일] GNU/리눅스의 뛰어난 가성비를 결정짓는 것은 클로즈드 소스 프로젝트에서는 불가능한 유연하고 역동적인 개발 시스템이다. 무료 개발의 저렴한 비용, 간소화된 테스트 및 배포 메커니즘, 문제에 대한 다양한 비전을 가진 여러 국가의 사람들의 참여, GPL 라이선스에 따른 코드 보호 - 이 모든 것이 자유 소프트웨어의 성공 이유가 되었습니다. 물론 이러한 높은 개발 효율성은 프로젝트를 시작한 대기업의 관심을 끌지 않을 수 없습니다. 이것이 Mozilla(Netscape, AOL), OpenOffice.org(Sun), Interbase(Borland) - Firebird, SAP DB(SAP)의 무료 클론이 등장한 방식입니다. IBM은 GNU/Linux를 메인프레임에 이식하는 데 중요한 역할을 했습니다. 반면에 오픈 소스는 GNU/Linux용 폐쇄 시스템 개발 비용을 크게 줄이고 사용자를 위한 솔루션 비용을 절감할 수 있습니다. 이것이 GNU/Linux가 Oracle, DB2, Informix, SyBase, SAP R3, Domino와 같은 제품에 자주 권장되는 플랫폼이 된 이유입니다. GNU/Linux 커뮤니티는 Linux 사용자 그룹을 통해 통신을 유지합니다. 대부분의 사용자는 배포판을 사용하여 GNU/Linux를 설치합니다. 배포 키트는 단순한 프로그램 세트가 아니라 패키지 설치, 관리 및 업데이트, 구성 및 지원을 위한 균일한 시스템으로 통합된 다양한 사용자 작업을 위한 일련의 솔루션입니다. 세계에서 가장 널리 보급된 배포판은 다음과 같습니다. - 학습 및 사용의 용이성에 중점을 둔 빠르게 인기를 얻고 있는 배포 키트 - Novell이 소유한 SuSE 배포 키트의 무료 배포 버전. YaST 유틸리티를 사용하여 구성 및 유지 관리가 용이함 - 커뮤니티 및 RedHat Corporation의 지원으로 RHEL의 상용 버전 이전 GNU/Linux는 비 사용자를 위해 광범위한 개발자 커뮤니티에서 개발한 국제 배포판입니다. - 상업적 목적. 다른 많은 배포판의 기초 역할을 했습니다. 비자유 소프트웨어의 포함에 대한 엄격한 접근 방식과 다릅니다. - 프랑스-브라질 배포, 구 Mandrake와 Conectiva(영어)의 합병 - 가장 오래된 배포 중 하나, 개발 및 사용에 대한 보수적 접근이 특징 - 소스 코드에서 빌드된 배포판입니다. 최종 시스템을 매우 유연하게 구성하고 성능을 최적화할 수 있으므로 종종 스스로를 메타 배포라고 합니다. 전문가 및 고급 사용자를 대상으로 - 최신 소프트웨어를 목표로 하고 지속적으로 업데이트되며 바이너리 및 소스 설치를 지원하고 단순함이라는 KISS 철학을 기반으로 하는 이 배포판은 완전한 기능과 Linux 수정 가능성을 원하지만 그렇지 않은 지식 있는 사용자를 대상으로 합니다. 유지 보수 시간의 희생. 나열된 배포판 외에도 나열된 배포판을 기반으로 하고 처음부터 만들어지며 제한된 수의 작업을 수행하도록 설계된 다른 배포판도 많이 있습니다. 그들 각각에는 고유한 개념, 고유한 패키지 세트, 고유한 장점과 단점이 있습니다. 그들 중 어느 것도 모든 사용자를 만족시킬 수 없기 때문에 다른 회사와 프로그래머 협회가 리더와 함께 행복하게 존재하며 솔루션, 배포 및 서비스를 제공합니다. Knoppix와 같이 GNU/Linux를 기반으로 구축된 LiveCD가 많이 있습니다. LiveCD를 사용하면 하드 드라이브에 설치하지 않고 CD에서 직접 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 install libgd2-dev 1) 새로운 사용자 권한 없는 계정 생성 Nagios 서비스를 실행하기 위해 새 계정이 생성됩니다. 수퍼유저 계정으로도 이 작업을 수행할 수 있으며 이는 시스템 보안에 심각한 위협이 됩니다. 슈퍼유저 되기: 새 nagios 사용자 계정을 만들고 암호를 지정합니다. # / usr / sbin / useradd -m -s / bin / bash nagios # passwd 나기오스 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-data 2) Nagios 및 플러그인 다운로드 다운로드한 파일을 저장할 디렉토리 생성: # mkdir ~ / 다운로드 # cd ~ / 다운로드 Nagios 및 해당 플러그인의 압축 소스 다운로드(# "justify"> # wget # "justify"> # wget # "justify"> 3) Nagios 컴파일 및 설치 압축된 Nagios 소스 코드의 압축을 풀자: # cd ~ / 다운로드 # tar xzf nagios-3.2.0.tar.gz # CD 나기오스-3.2.0 Nagios 구성 스크립트를 실행하여 이전에 생성한 그룹의 이름을 전달합니다. # ./configure --with-command-group = nagcmd 구성 스크립트의 전체 매개변수 목록: #. / 구성 --help 'configure'는 이 패키지를 여러 종류의 시스템에 적용하도록 구성합니다.: ./configure ... ... 환경 변수(예: CC, CFLAGS ...)를 할당하고 = VALUE로 지정합니다. 일부 설명은 아래를 참조하십시오. 유용한 변수의 옵션은 대괄호로 지정됩니다.: h, --help 이 도움말을 표시하고 종료 도움말 = 이 패키지와 관련된 짧은 표시 옵션 도움말 = 포함된 모든 패키지의 짧은 도움말을 재귀적으로 표시합니다. V, --version 버전 정보 표시 및 종료 q, --quiet, --silent `검사 중 ...' 메시지를 인쇄하지 않음 캐시 파일 = FILE의 FILE 캐시 테스트 결과 C, `--cache-file = config.cache'에 대한 --config-cache 별칭 n, --no-create 출력 파일을 생성하지 않음 Srcdir = DIR은 DIR 디렉토리에서 소스를 찾습니다. 접두사 = PREFIX는 PREFIX에 아키텍처 독립 파일을 설치합니다. Exec-prefix = EPREFIX EPREFIXdefault에 아키텍처 종속 파일 설치, `make install'은 `/ usr / local / nagios / bin", `/ usr / local / nagios / lib" 등에 있는 모든 파일을 설치합니다. 다음을 지정할 수 있습니다. `/ usr / local / nagios" 이외의 설치 접두사를 `--prefix'를 사용하여 사용합니다(예: `--prefix = $ HOME" .better control, 아래 옵션을 사용하십시오. 설치 디렉토리 조정: Bindir = DIR 사용자 실행 파일 Sbindir = DIR 시스템 관리자 실행 파일 Libeexecdir = DIR 프로그램 실행 파일 Datadir = DIR 읽기 전용 아키텍처 독립 데이터 Sysconfdir = DIR 읽기 전용 단일 시스템 데이터 Sharedstatedir = DIR 수정 가능한 아키텍처 독립적 데이터 Localstatedir = DIR 수정 가능한 단일 머신 데이터 Libdir = DIR 개체 코드 라이브러리 Includedir = DIR C 헤더 파일 Oldincludedir = 비 gcc에 대한 DIR C 헤더 파일 Infodir = DIR 정보 문서 Mandir = DIR man 문서 유형: Build = BUILD에서 빌드하기 위한 BUILD 구성 Host = HOST에서 크로스 컴파일하여 HOST 기능에서 실행할 프로그램을 빌드합니다. Disable-FEATURE는 FEATURE를 포함하지 않습니다(--enable-FEATURE = no와 동일). Enable-FEATURE [= ARG] 기능 포함 Disable-statusmap = 상태 맵 CGI 컴파일 비활성화 Disable-statuswrl = statuswrl(VRML) CGI 컴파일 비활성화 Enable-DEBUG0은 기능 시작 및 종료를 표시합니다. Enable-DEBUG1은 일반 정보 메시지를 표시합니다. Enable-DEBUG2는 경고 메시지를 표시합니다. Enable-DEBUG3는 예약된 이벤트를 표시합니다(서비스 및 호스트 확인 등). Enable-DEBUG4는 서비스 및 호스트 알림을 표시합니다. Enable-DEBUG5는 SQL 쿼리를 보여줍니다. Enable-DEBUGALL은 모든 디버깅 메시지를 표시합니다. Enable-nanosleep은 이벤트 타이밍에서 nanosleep(수면 대신) 사용을 활성화합니다. Enable-event-broker는 이벤트 브로커 루틴의 통합을 가능하게 합니다. Enable-embedded-perl은 임베디드 Perl 인터프리터를 활성화합니다. Enable-cygwin을 사용하면 CYGWIN 환경에서 빌드할 수 있습니다.패키지: 패키지 포함 [= ARG] 패키지 사용 without-PACKAGE는 PACKAGE를 사용하지 않습니다(--with-PACKAGE = no와 동일). with-nagios-user = with-nagios-group = 명령 사용자 = 명령 그룹 포함 = 메일로 = with-init-dir = 잠금 파일 포함 = With-gd-lib = DIR은 gd 라이브러리의 위치를 설정합니다. With-gd-inc = DIR은 gd 포함 파일의 위치를 설정합니다. with-cgiurl = with-htmurl = With-perlache는 내부적으로 컴파일된 Perl 스크립트의 캐싱을 켭니다.영향력 있는 환경 변수: C 컴파일러 명령C 컴파일러 플래그링커 플래그, 예. -엘 Nagios 소스 코드를 컴파일합니다. 바이너리, 초기화 스크립트, 구성 파일의 예를 설치하고 외부 명령 디렉토리에 대한 권한을 설정해 보겠습니다. # 설치 초기화 # 설치 구성을 만듭니다. # 설치 명령 모드를 만듭니다. ) 구성 변경 샘플 구성 파일은 / usr / local / nagios / etc 디렉토리에 설치됩니다. 그들은 즉시 일해야 합니다. 계속하기 전에 한 가지만 변경하면 됩니다. 텍스트 편집기로 구성 파일 /usr/local/nagios/etc/objects/contacts.cfg를 편집하고 nagiosadmin 연락처 정의와 연결된 이메일 주소를 오류 메시지를 수신할 주소로 변경하겠습니다. # vi /usr/local/nagios/etc/objects/contacts.cfg 5) 웹 인터페이스 구성 Apache conf.d 디렉토리에 Nagios 프론트엔드 구성 파일을 설치합니다. # install-webconf를 만듭니다. Nagios 웹 인터페이스에 로그인하려면 nagiosadmin 계정을 만드십시오. # htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin 변경 사항을 적용하려면 Apache를 다시 시작하십시오. # /etc/init.d/apache2 다시 로드 모니터링 정보는 매우 민감한 정보이므로 이 계정의 도용을 방지하기 위해 CGI의 보안을 강화하는 조치가 필요합니다. ) Nagios 플러그인 컴파일 및 설치 Nagios 플러그인의 압축 소스 코드를 풀어보겠습니다. # cd ~ / 다운로드 # tar xzf nagios-plugins-1.4.11.tar.gz 플러그인 컴파일 및 설치: # ./configure --with-nagios-user = nagios --with-nagios-group = nagios #설치하다 ) Nagios 서비스 시작 운영 체제가 켜져 있을 때 자동으로 부팅되도록 Nagios를 구성해 보겠습니다. # ln -s /etc/init.d/nagios /etc/rcS.d/S99nagios 예제 구성 파일의 구문이 올바른지 확인해 보겠습니다. # / usr / 로컬 / nagios / bin / nagios -v /usr/local/nagios/etc/nagios.cfg 오류가 없으면 Nagios를 시작하십시오. # /etc/init.d/nagios 시작 ) 웹 인터페이스를 입력 이제 다음 URL을 사용하여 Nagios 웹 인터페이스에 로그인할 수 있습니다. 이전에 설정한 사용자 이름(nagiosadmin)과 비밀번호를 입력하라는 메시지가 표시됩니다. # "justify">) 기타 설정 Nagios 이벤트에 대한 이메일 알림을 받으려면 mailx(Postfix) 패키지를 설치해야 합니다. % sudo apt-get install mailx % sudo apt-get 설치 접미사 /usr/local/nagios/etc/objects/commands.cfg 파일에서 Nagios 알림 명령을 편집하고 모든 링크를 "/ bin / mail"에서 "/ usr / bin / mail"로 변경해야 합니다. 그런 다음 Nagios 서비스를 다시 시작해야 합니다. # sudo /etc/init.d/nagios 다시 시작 메일 모듈의 자세한 구성은 부록 D에 설명되어 있습니다. 4.1.2 저장소에서 시스템 커널 설치 설명 위에 표시된 것처럼 소스에서 Nagios를 설치하는 것은 상당한 시간이 걸리며 애플리케이션의 세심한 최적화가 필요하거나 시스템 작동 방식을 철저히 이해하려는 경우에만 의미가 있습니다. 프로덕션 환경에서 대부분의 소프트웨어는 사전 컴파일된 패키지로 리포지토리에서 설치됩니다. 이 경우 설치는 하나의 명령을 입력하는 것으로 축소됩니다. % sudo 적성 설치 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 파일이 포함되어 있으며, 이 파일에서 아파치 웹 서버가 nagios에 대한 설정을 가져옵니다. nagios 구성 파일은 /etc/nagios3 디렉토리에 있습니다. /etc/nagios3/htpasswd.users 파일에는 nagios 사용자의 비밀번호가 포함되어 있습니다. 파일을 생성하고 nagios 사용자의 기본 비밀번호를 설정하는 명령은 위에 나와 있습니다. 앞으로는 새 사용자의 암호를 지정할 때 "-c" 인수를 생략해야 합니다. 그렇지 않으면 새 파일이 이전 암호를 덮어씁니다. /etc/nagios3/nagios.cfg 파일에는 nagios 자체에 대한 기본 구성이 포함되어 있습니다. 예를 들어 이벤트 로그 파일 또는 nagios가 시작 시 읽는 나머지 구성 파일의 경로입니다. 새 호스트 및 서비스는 /etc/nagios/objects 디렉토리에 정의됩니다. 4.2.3 호스트 및 서비스에 대한 설명 완성 위와 같이 호스트 및 서비스에 대한 단일 설명 파일을 사용하여 시스템 커널을 구성할 수 있지만 이 방법은 모니터링되는 장비의 수가 증가함에 따라 편리하지 않으므로 특정 디렉토리 구조 및 설명이 포함된 파일을 생성해야 합니다. 호스트 및 서비스의. 생성된 구조는 부록 H에 나와 있습니다. Hosts.cfg 파일 먼저 모니터링할 호스트를 설명해야 합니다. 원하는 만큼 호스트를 설명할 수 있지만 이 파일에서는 모든 호스트에 대한 일반 매개변수로 제한합니다. 여기에 설명된 호스트는 실제 호스트가 아니라 다른 모든 호스트 설명의 기반이 되는 템플릿입니다. 구성이 미리 정의된 기본값 집합을 기반으로 하는 경우 다른 구성 파일에서도 동일한 메커니즘을 찾을 수 있습니다. Hostgroups.cfg 파일 여기에서 호스트가 호스트 그룹에 추가됩니다. 간단한 구성에서도 호스트가 하나만 있는 경우 Nagios가 알림을 보내는 데 사용할 연락처 그룹을 알 수 있도록 호스트를 그룹에 추가해야 합니다. 연락처 그룹에 대한 자세한 내용은 아래를 참조하세요. Contactgroups.cfg 파일 연락처 그룹을 정의하고 이 그룹에 사용자를 추가했습니다. 이 구성을 사용하면 그룹이 담당하는 서버에 문제가 있는 경우 모든 사용자에게 경고가 표시됩니다. 그러나 각 사용자의 개별 설정이 이러한 설정을 무시할 수 있다는 점을 염두에 두어야 합니다. 다음 단계는 연락처 정보 및 경고 설정을 제공하는 것입니다. Contacts.cfg 파일 이 파일의 사용자에 대한 추가 연락처 정보를 제공하는 것 외에도 contact_name 필드 중 하나에는 다른 용도가 있습니다. CGI 스크립트는 이 필드에 제공된 이름을 사용하여 사용자에게 특정 리소스에 액세스할 수 있는 권한이 있는지 여부를 결정합니다. .htaccess를 기반으로 인증을 설정해야 하지만 사용자가 웹 인터페이스를 통해 작업하려면 위에서 사용한 것과 동일한 이름을 사용해야 합니다. 이제 호스트와 연락처가 구성되었으므로 모니터링해야 하는 개별 서비스의 모니터링 구성을 진행할 수 있습니다. Services.cfg 파일 여기에서는 호스트에 대한 hosts.cfg 파일에서와 같이 모든 서비스에 대해 일반 매개변수만 설정합니다. 사용할 수 있는 추가 Nagios 모듈이 엄청나게 많지만 여전히 체크가 없으면 언제든지 직접 작성할 수 있습니다. 예를 들어 Tomcat이 실행 중인지 여부를 확인하는 모듈이 없습니다. 원격 Tomcat 서버에서 jsp 페이지를 로드하고 로드된 페이지에 페이지에 일부 텍스트가 포함되어 있는지 여부에 따라 결과를 반환하는 스크립트를 작성할 수 있습니다. (새 명령을 추가할 때 우리가 건드리지 않은 checkcommand.cfg 파일에서 그것을 언급해야 합니다). 또한 각 개별 호스트에 대해 자체 설명 파일을 만들고 동일한 파일에 이 호스트에 대해 모니터링할 서비스에 대한 설명을 저장할 것입니다. 이것은 편의와 논리적 구성을 위해 수행됩니다. Windows 호스트는 SNMP 및 NSClient를 통해 모니터링됩니다. Nagios와 함께 배송됩니다. 아래는 작업 다이어그램입니다. 쌀. 4.3 - Windows 호스트 모니터링 계획 동시에 * nix 호스트도 SNMP 및 NRPE 플러그인을 통해 모니터링됩니다. 작업 계획이 그림에 나와 있습니다. 쌀. 4.4 - 모니터링 계획 * nix 호스트 2.4 플러그인 작성 초기화 스크립트 작성, 호스트 및 서비스 정의 외에도 다음 플러그인이 사용되었습니다. ├── 체크 디스크 ├── check_dns ├── check_http ├── check_icmp ├── check_ifoperstatus ├── check_ifstatus ├── check_imap -> check_tcp ├── check_linux_raid ├── 체크_로드 ├── check_mrtg ├── check_mrtgtaf ├── 체크_nrpe ├── check_nt ├── 체크_핑 ├── check_pop -> check_tcp ├── check_sensors ├── check_simap -> check_tcp ├── 체크_smtp ├── check_snmp ├── check_snmp_load.pl ├── check_snmp_mem.pl ├── check_spop -> check_tcp ├── check_ssh ├── check_ssmtp -> check_tcp ├── check_swap ├── check_tcp ├── 확인 시간 대부분은 Nagios 패키지와 함께 제공됩니다. 제공 세트에 포함되지 않고 시스템에서 사용되는 플러그인의 소스 텍스트는 부록 I에 나와 있습니다. 4.2.5 원격 호스트에서 SNMP 구성 SNMP 프로토콜을 사용하여 모니터링하려면 먼저 네트워크 장비에서 이 프로토콜의 에이전트를 구성해야 합니다. 네트워크 모니터링 시스템의 핵심과 연계된 SNMP 동작의 다이어그램은 아래 그림과 같습니다. 쌀. 4.5 - SNMP 프로토콜을 통한 모니터링 방식 호스트의 구성 매개변수는 부록 H에 나와 있습니다. 보안은 각 호스트에서 개별적으로 패킷 필터를 개별적으로 구성하고 기업의 승인된 직원만 액세스할 수 있는 보안 시스템 서브넷을 구성하여 수행됩니다. 또한 SNMP 프로토콜을 사용하면 매개변수를 읽을 수만 있고 쓸 수 없도록 설정됩니다. 4.2.6 원격 호스트에서 에이전트 구성 호스트 및 서비스에 대한 고급 모니터링을 얻으려면 nagios-nrpe-server라는 Nagios 에이전트를 설치해야 합니다. # aptitude 설치 nagios-nrpe-server 에이전트 구성은 부록 K에 나와 있습니다. 에이전트 워크플로는 위의 그림 4.5에 나와 있습니다. 4.4 다운로드 추적 모듈 설치 및 구성 MRTG(Multi Router Traffic Grapher)는 SNMP 프로토콜을 사용하여 여러 장치에서 정보를 수신하고 브라우저 창에 채널 부하(들어오는 트래픽, 나가는 트래픽, 최대값, 평균) 그래프를 분, 시간, 일 및 연간. 설치 요구 사항 MRTG가 작동하려면 다음 라이브러리가 필요합니다. § gd - 그래프 그리기 라이브러리. 그래픽 형성을 담당하는 라이브러리(# "justify"> § libpng - gd는 png 형식의 그래픽을 생성하는 데 필요합니다(# "justify"> 우리의 경우 저장소에서 미리 컴파일된 패키지를 설치하는 방법이 선택되었으므로 설치가 하나의 명령 실행으로 축소됩니다. # 적성 설치 mrtg 구성 파일을 수동으로 생성하거나 패키지에 포함된 구성 생성기를 사용할 수 있습니다. # cfg메이커 구성 파일을 생성한 후 확인하는 것이 좋습니다. 여기에는 워크로드에 대해 분석할 필요가 없는 인터페이스에 대한 설명이 포함될 수 있습니다. 이 경우 파일의 특정 행이 주석 처리되거나 삭제됩니다. MRTG 구성 파일의 예는 부록 M에 나와 있습니다. 이러한 파일의 크기가 크기 때문에 하나의 파일에 대한 예만 제공됩니다. # 인덱스메이커 인덱스 페이지는 일반적인 html 파일이며 그 내용은 특별히 관심을 두지 않으므로 예를 들어 설명하는 것은 의미가 없습니다. 부록 H는 인터페이스 부하 그래프를 표시하는 예를 보여줍니다. 마지막으로 일정에 따라 인터페이스에 대한 부하 검사를 구성해야 합니다. 이를 달성하는 가장 쉬운 방법은 운영 체제, 즉 crontab 매개변수를 사용하는 것입니다. 4.5 시스템 이벤트 로그 수집을 위한 모듈 설치 및 구성 syslog-ng.ng(syslog next generation) 패키지는 시스템 이벤트 로그 수집을 위한 모듈로 선택되었습니다. 이것은 시스템 메시지 로깅을 위한 다기능 서비스입니다. 표준 syslogd 서비스와 비교할 때 다음과 같은 여러 차이점이 있습니다. § 개선된 구성 다이어그램 § 우선 순위뿐만 아니라 내용별로 메시지 필터링 § regexp 지원(정규 표현식) § 보다 유연한 로그 조작 및 구성 § IPSec/Stunnel을 사용하여 데이터 전송 채널을 암호화하는 기능 다음 표에는 지원되는 하드웨어 플랫폼이 나열되어 있습니다. 표 4.1 - 지원되는 하드웨어 플랫폼 x86x86_64SUN SPARCppc32ppc64PA-RISCAIX 5.2 5.3NetNetNetDaPo zaprosuNetDebian etchDaDaNetNetNetNetFreeBSD 6.1 * DaPo zaprosuPo zaprosuNetNetNetHP-유넷 11iNetNetNetNetNetDaIBM 시스템 iNetNetNetDaNetNetRed 모자 ES 4 / CentOS는 4DaDaNetNetNetNetRed 모자 ES 5 / 10에 CentOS 5DaDaNetNetNetNetSLES / 수세 10.0DaPo zaprosuNetNetNetNetSLES 10 SP1 / 수세 10.1DaDaNetNetNetNetSolaris 8NetNetDaNetNetNetSolaris 9Po zaprosuNetDaNetNetNetSolaris 10After zaprosuDaDaNetNetNetWindowsDaDaNetNetNetNet 참고: * Oracle 데이터베이스 액세스는 지원되지 않습니다. 기술적 특징에 대한 자세한 비교는 부록 A에 나와 있습니다. 규칙과 필터를 설명하는 파일과 원격 호스트의 구성은 부록 P에 나와 있습니다. syslog 프로토콜을 자세히 설명하는 RFC 문서가 있으며 일반적으로 syslog 수집기 모듈의 작동은 다음 다이어그램으로 나타낼 수 있습니다. 쌀. 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 시스템 이벤트 로그 수집 모듈 설명 현재로서는 향상된 시스템 로그 필터링과 단일 웹 인터페이스를 통한 검색 기능이 필요하지 않습니다. 이러한 로그를 봐야 하는 문제는 드뭅니다. 따라서 이러한 잡지 및 웹 인터페이스에 대한 데이터베이스 개발이 연기되었습니다. 현재 mc 파일 관리자에서 ssh 및 디렉토리 탐색을 통해 액세스합니다. 이 모듈의 작업 결과 다음과 같은 디렉토리 구조를 얻었습니다. ├── 아파치2 ├── 별표 ├── bgp_router ├── dbconfig-common ├── 설치 프로그램 │ └── cdebconf ├── len58a_3lvl ├── 모니터링 ├── 나기오스3 │ └── 아카이브 ├── ocsinventory-client ├── ocsinventory-server ├── 콰가 ├── router_krivous36b ├── 라우터_lenina58a ├── 라우터_수 ├── 라우터_ur39a ├── 셰이퍼 ├── ub13_router ├── univer11_router └── 보이프 각 디렉토리는 각 개별 호스트에 대한 이벤트 로그의 리포지토리입니다. 쌀. 5.13 - 시스템 이벤트 로그 수집 모듈에서 수집한 데이터 보기 6. 작업 테스트 시스템을 구현하는 동안 시스템의 핵심을 시작으로 각 구성 요소의 작동에 대한 점진적인 테스트가 수행되었습니다. 기능 확장은 다양한 하위 시스템의 많은 종속성으로 인해 계층 구조에서 네트워크 모니터링 시스템 모듈의 하위 수준을 최종 조정한 후에만 수행되었습니다. 일반적으로 다음과 같이 구현 및 테스트 프로세스를 단계별로 설명할 수 있습니다. ) Nagios 기반 커널 설치 및 디버깅 ) Nagios의 기본 기능으로 원격 호스트 모니터링 설정 ) MRTG를 통해 네트워크 인터페이스의 부하를 모니터링하기 위한 모듈 설정 ) 시스템 코어의 기능 확장 및 MRTG 모듈과의 통합 ) 시스템 로그 수집을 위한 모듈 조정 ) 시스템 보안을 보장하기 위해 모니터링 시스템의 패킷 필터를 초기화하는 스크립트를 작성합니다. 7. 정보보안 1 직장의 특성 PC를 사용할 때 작업에 영향을 미치는 유해 요소는 다음과 같습니다. · 전류 전압의 증가된 값; · 소음; · 전자기 방사선; · 정전기장. 효율적이고 안전한 작업을 위한 최상의 조건을 보장하기 위해서는 이러한 유해 요소의 영향을 최소화하고 편안할 수 있는 작업 환경을 조성하는 것이 필요합니다. 나열된 유해 요소는 확립된 규칙 및 규정과 일치해야 합니다. 7.2 산업안전 2.1 전기적 안전 계획된 소프트웨어 도구는 특별히 설비된 기술실에 있는 기존 서버에서 작업할 것으로 예상하여 만들어집니다. 케이블 라우팅을 위한 케이블 덕트가 장착되어 있습니다. 각 서버에는 작업 접지가 있는 ~ 220V 전원 공급 장치, 50Hz가 제공됩니다. 방에 전원 공급 장치를 입력하기 전에 단락이 발생하면 전원 공급 장치를 차단하는 자동 장치가 설치됩니다. 보호 접지는 별도로 수행됩니다. 컴퓨터를 연결할 때 장비 케이스를 보호 접지 도체에 연결하여 절연 실패 또는 기타 이유로 사람이 장비 케이스를 만졌을 때 위험한 전원 공급 장치 전압이 발생하지 않도록 해야 합니다. 인체에 위험한 전류. 이렇게 하려면 보호 접지 도체에 연결된 전기 콘센트의 세 번째 접점을 사용하십시오. 장비 인클로저는 전용 도체를 사용하여 전원 공급 케이블을 통해 접지됩니다. 충전부가 절연 파손된 경우 전기 설비 본체를 만질 때 감전을 방지하기 위해 다음과 같은 기술적 조치가 적용됩니다. · 보호 접지; · 보호 접지; · 보호 종료. 7.2.2 소음 방지 연구에 따르면 청력 손실은 소음에서 가장 중요한 요소입니다. 그러나 소음의 영향은 청각에만 미치는 영향에 국한되지 않습니다. 그것은 많은 생리적 정신 기능에 눈에 띄는 변화를 일으킵니다. 소음은 신경계에 해로운 영향을 미치고 감각 운동 과정의 속도와 정확성을 감소시키며 지적 문제를 해결하는 데 오류가 증가합니다. 소음은 사람의 주의력에 눈에 띄는 영향을 미치고 부정적인 감정을 유발합니다. 컴퓨터가 있는 방의 주요 소음원은 에어컨 장비, 인쇄 및 복사 장비, 그리고 컴퓨터 자체의 냉각 팬입니다. 생산 영역에서 다음과 같은 소음 제어 조치가 적극적으로 사용됩니다. · 조용한 냉각 메커니즘의 사용; · 방음 및 흡음에 의한 환경으로부터 소음원의 격리; · 건물을 마주하기 위해 흡음재 사용. 직장의 작업장에는 다음과 같은 소음원이 있습니다. · 시스템 장치(쿨러(25dB), 하드 디스크(29dB), 전원 공급 장치(20dB)); · 프린터(49dB). 이러한 장치에서 방출되는 총 소음 L은 다음 공식을 사용하여 계산됩니다. 여기서 Li는 한 장치의 소음 수준, dB = 10 * log(316.23 + 794.33 + 100 + 79432.82) = 10 * 4.91 = 49.1dB입니다. SN 2.2.4 / 2.1.8.562-96에 따르면 수학자-프로그래머 및 비디오 운영자의 작업장 소음 수준은 50dB를 초과해서는 안됩니다. 7.2.3 전자기 복사에 대한 보호 전자기 간섭에 대한 보호는 전기 전도성 표면이 있는 스크린과 유해한 방사선 수준을 최소화하는 저방사선 시스템이 장착된 모니터 및 전자기 방사선이 전혀 없는 액정 모니터를 사용하여 제공됩니다. 7.2.4 정전기장에 대한 보호 정전기로부터 보호하기 위해 접지된 보호 필터, 가습기가 사용되며 바닥은 정전기 방지 코팅으로 덮여 있습니다. 컴퓨터가 있는 방의 양이온과 음이온 농도의 표준화된 값을 유지하기 위해 에어컨, 공기 이온화 장치를 설치하고 2시간 작동 후 최소 10분 동안 자연 환기를 수행합니다. 에어로이노가 함유된 먼지 입자가 작업자의 유기체에 미치는 유해한 영향을 방지하기 위해 구내 습식 청소를 매일 수행하고 교대당 최소 1회 모니터가 꺼진 상태에서 화면의 먼지를 제거합니다. 7.3 근무 조건 3.1 생산 지역의 미기후 이 디플로마 프로젝트에서 고려되는 장비는 작동 중 유해 물질을 생성하지 않습니다. 따라서 사용되는 방의 공기 환경은 인체에 유해한 영향을 미치지 않으며 GOST 12.1.005-88에 따라 작업 범주 I의 요구 사항을 충족합니다. 산업 건물의 작업 영역에서 온도, 상대 습도 및 풍속의 최적 기준은 GOST 12.1.005-88에 의해 표준화되었으며 표 7.1에 나와 있습니다. 표 7.1 - 소기후 매개변수 표준화된 매개변수 값 최적 허용 실제 대기 온도, C20 - 2218 - 2020 습도, % 40 - 60 8045 이하 풍속, m / s0.20.30..0.3 미기후는 최적의 조건에 해당합니다. 3.2 산업용 조명 계산을 위해 이 프로젝트의 개발이 진행된 Verkhnyaya Pyshma 시에 있는 Gerkon LLC의 지원 부서를 선택합니다. · 방의 면적은 60m2입니다. · 가벼운 개구부 면적 10m2; · 4대의 자동화 워크스테이션이 설치되었습니다. 자연 조명 계산은 SNiP 23.05-95 공식에 따라 이루어집니다. S0 = Sп * en * Кз * N0 * KZD / 100% * Т0 * Т1 (7.2)
여기서 S0는 가벼운 개구부의 면적, m2입니다. Sп - 방의 바닥 면적, m2, 60; eн - 자연 조명 계수, 1.6; Кз - 안전 계수, 1.5; N0 - 창문의 빛 특성, 1; KZD - 반대 건물에 의한 창문 어두워짐을 고려한 계수, 1.2; T0는 일반 광 투과 계수, 0.48입니다. T1 - 방 표면에서의 반사 계수, 1.2. 모든 계수의 값은 SNiP 23.05.-95에서 가져옵니다. 계산 결과, 우리는 다음을 얻습니다. 창 S0 = 3.4m2의 가벼운 개구부의 필요한 면적. 개구부의 실제 면적은 10m2로, 이러한 유형의 방에 대한 최소 허용 가능한 가벼운 개구부 면적을 초과하며 낮 시간 동안 충분합니다. 각각 60W의 전력으로 LDTs-60 유형의 15개 형광등으로 조명되는 방의 인공 조명 계산. SNiP 23.05-95에 따르면 형광등의 조명량은 일반 조명 시스템의 경우 수평면에서 최소 300lm이어야 합니다. 높은 정확도의 시각적 작업을 고려하여 조명 값을 최대 1000lm까지 높일 수 있습니다. 형광등의 광속은 SNiP 23.05.-95의 공식을 사용하여 계산됩니다. 파이 = En * S * Z * K / N * η (7.3)
어디 En - 정규화된 실내 조명, 럭스, 200; S - 방의 바닥 면적, m2, 60; Z - 최소 조명에 대한 평균의 비율을 고려한 계수, 1.1; K는 대기 오염을 고려한 안전 계수, 1.3; N - 램프 수, 15; η - 광속 이용 계수, 0.8. 결과적으로 우리는 Phi = 1340lm을 얻고 모든 램프의 총 광속은 3740lm이므로 실험실의 조명이 허용되는 최소값보다 높습니다. 7.4 작업장의 인체 공학 4.1 작업장 구성 SanPiN 2.2.2 / 4.2.1340-03에 따라 VDT(비디오 디스플레이 터미널)는 다음 기술 요구 사항을 충족해야 합니다. · 100cd / m2 이상의 조명 밝기; · 라이트 포인트의 최소 크기는 컬러 디스플레이의 경우 0.1mm 이하입니다. · 기호 이미지의 대비는 0.8 이상입니다. · 수직 주사 주파수 7kHz 이상 · 포인트 수는 640 이상입니다. · 화면의 반사 방지 코팅; · 화면 크기는 대각선으로 31cm 이상; · 화면의 문자 높이는 3.8mm 이상이어야 합니다. · 작업자의 눈에서 화면까지의 거리는 약 40-80cm이어야 합니다. RCCB에는 130~220mm 내에서 수평 및 수직 평면으로 이동하고 화면 기울기 각도를 10~15도 변경할 수 있는 턴테이블이 장착되어야 합니다. 디플로마 프로젝트는 39cm ViewSonic VDT가 장착된 컴퓨터에서 진행되었습니다. 이 모니터는 글로벌 표준에 따라 제조되었으며 위의 모든 기술 요구 사항을 충족합니다. 키보드에는 다음 요구 사항이 적용됩니다. · 확산 광 확산으로 차분하고 부드러운 색상의 바디 페인팅; · 반사율이 0.4 - 0.6이고 눈부심을 유발할 수 있는 반짝이는 부분이 없는 무광택 표면; 프로젝트는 위의 모든 요구 사항을 충족하는 Logitech 브랜드 키보드에서 수행되었습니다. 시스템 장치는 플로피 드라이브에 쉽게 액세스할 수 있고 뒷면에 있는 커넥터 및 컨트롤에 쉽게 액세스할 수 있는 작업장에 설치됩니다. 자주 사용하는 플로피 디스크는 먼지와 전자기 보호 셀에 시스템 장치 근처에 보관됩니다. 사용자의 오른쪽에 있는 프린터입니다. 인쇄된 텍스트는 작업자가 주요 작업 위치에 있을 때 볼 수 있습니다. 백지 및 기타 필수 소모품은 프린터와 가까운 전용 구획에 보관됩니다. 연결 케이블은 특수 덕트에 배치됩니다. 커넥터가 케이블 제거를 방해하지 않도록 채널을 배열해야 합니다. 사용자의 오른쪽에 있는 "마우스"와 같은 조작기의 경우 화면 표면과 모양과 크기가 같아야 하는 여유 공간이 있습니다. 운영자의 작업장은 GOST 12.2.032-78 SSBT의 요구 사항을 충족합니다. 작업장의 공간 구성은 최적의 작업 자세를 보장합니다. · 머리는 10-20도 앞으로 기울어집니다. · 등받이가 있고 어깨와 팔뚝의 비율과 허벅지와 다리의 비율이 직각입니다. 작업장의 주요 매개변수는 조정 가능해야 합니다. 이것은 지리학적 특성을 고려하여 개인에게 유리한 근무 조건을 조성할 가능성을 보장합니다. 개인용 컴퓨터가 장착 된 작업장 및 가구의 주요 매개 변수 (그림 7.1) 쌀. 7.1 - 컴퓨터 운영자의 워크스테이션 · 좌석 높이 42 - 45 cm; · 바닥에서 키보드의 높이는 70 - 85cm입니다. · 수평에서 키보드의 경사각 7 - 15도; · 테이블 가장자리에서 키보드의 원격 10 - 26cm; · 화면 중앙에서 바닥까지의 거리 90 - 115cm; · 수직 0 - 30도(최적 15도)에서 화면의 기울기 각도; · 테이블 가장자리에서 화면까지의 거리 50 - 75 cm; · 기록의 작업 표면 높이 74 - 78 cm; 작업장에는 앉은 자세에서 장기 보존과 관련된 모든 유형의 작업에 권장되는 발 받침대가 제공됩니다. SanPiN 2.2.2.542-96에 따르면 컴퓨터 운영자의 작업 특성은 쉬운 것으로 간주되며 범주 1A에 속합니다. 교대근무 시작 후 2시간 후, 점심시간 후 2시간 후 휴식시간이 각각 15분씩 있습니다. 규제 된 휴식 시간에는 신경 정서적 스트레스, 피로를 줄이고 운동 저하증의 영향을 제거하기 위해 복합 운동이 수행됩니다. 7.5 화재 안전 이 프로젝트의 작업이 수행된 방은 NPB 105-03에 화재 위험 범주가 설정되었습니다. 물, 산소 공기 또는 서로 상호 작용하여 화상을 입는 것입니다. 단, 사용 가능하거나 형성되는 건물은 범주 A 또는 B에 속하지 않습니다. SNiP 21-01에 따른 내화 등급 I의 건물 -97. 생산 구역에서는 다음과 같은 안전 규칙을 준수합니다. · 통로, 구내 출구, 소화 수단에 대한 접근은 무료입니다. · 작동 중인 장비가 제대로 작동하고 있으며 작업을 시작하기 전에 매번 점검합니다. · 작업이 끝나면 방을 검사하고 전원 공급 장치의 전원을 끄고 방을 닫습니다. 건물에서 건물의 대피 출구 수는 2입니다. 피난구(문)의 폭은 2m입니다. 탈출 경로는 일반 계단과 스윙 도어를 사용합니다. 계단통에는 건물, 기술 커뮤니케이션, 승강기 출구 및 화물용 엘리베이터가 없습니다. 대피 경로에는 자연 및 인공 비상 조명이 모두 장착되어 있습니다. 실내 소화의 주요 수단으로 실내에 2대의 휴대용 이산화탄소 소화기가 있습니다. 점화의 초기 단계를 감지하고 소방 서비스에 경고하기 위해 자동 및 화재 경보 시스템(APS)이 사용됩니다. 화재가 대형화될 때까지 자체적으로 소화설비를 가동하여 시 소방서에 신고합니다. APS를 제외한 전시장의 대상물은 고정식 소화설비를 갖추어야 한다. 소화 가스 물질로 건물을 빠르게 채우는 작업을 기반으로하는 가스 소화 화재 설치의 적용 결과 공기 중 산소 함량이 감소합니다. 7.6 비상사태 화재는 이 방에서 가장 가능성이 높은 비상 사태입니다. 화재가 발생하면 인원을 대피시키고 소방대에 사고를 보고해야 합니다. 대피 계획은 그림 7.2에 나와 있습니다. 쌀. 7.2 - 화재 탈출 계획 8. 경제 부문 이 섹션에서는 네트워크 모니터링 시스템, 구현 및 유지 관리, 관련 재료 및 장비 개발 비용에 대해 설명합니다. 프로젝트 비용은 개발 및 생산 과정에서 소비되는 노동 수단 및 대상의 비용(감가상각비, 장비, 자재, 연료, 에너지 등의 비용), 생활 노동 비용(인건비)의 일부를 반영합니다. 보수), 시스템 모듈 구입 비용. 활동과 서비스 공급량의 증가 과정에서 네트워크 조직의 결함 및 약점을 사전에 감지하는 문제가 발생했습니다. 즉, 교체 또는 현대화의 필요성을 예측할 수있는 솔루션을 구현하는 것이 과제였습니다. 결함 이전의 네트워크 섹션은 가입자 노드의 작동에 영향을 미칩니다. 클라이언트 기반의 성장과 그 결과 활성 장비의 수가 증가함에 따라 네트워크 전체와 개별 요소의 상태를 신속하게 상세하게 모니터링하는 것이 필요하게 되었습니다. 네트워크 모니터링 시스템을 구현하기 전에 네트워크 관리자는 telnet, http, snmp, ssh 등의 프로토콜을 사용하여 연결해야 했습니다. 관심 있는 각 네트워크 노드에 연결하고 내장된 모니터링 및 진단 도구를 사용합니다. 현재 네트워크 용량은 포트 5,000개, Layer 2 스위치 300개, 라우터 15개, 내부 서버 20개입니다. 또한 심각한 사용자 문제가 발생한 경우에만 네트워크 혼잡 및 부동 장애를 감지하여 네트워크 업그레이드 계획을 세울 수 없었습니다. 이 모든 것은 무엇보다도 제공되는 서비스의 품질이 지속적으로 저하되고 시스템 관리자 및 사용자에 대한 기술 지원에 대한 부담이 증가하여 막대한 손실을 초래했습니다. 현재 상황에 따라 위의 모든 문제를 해결할 수 있는 네트워크 모니터링 시스템을 개발 및 구현하기로 결정했으며, 이를 요약하면 다음과 같습니다. 스위치, 다른 제조업체의 라우터 및 다른 플랫폼의 서버를 모두 모니터링할 수 있는 모니터링 시스템을 개발하고 구현해야 합니다. 경제적인 관점에서 최종 시스템 라이선스 비용을 0으로 줄이는 자유 소프트웨어 기금의 기성품 개발을 최대한 활용하여 개방형 프로토콜 및 시스템 사용에 중점을 둡니다. 시스템은 다음과 같은 경제적 요구 사항을 충족해야 합니다. · 하드웨어 리소스에 대한 최소 요구 사항(프로젝트의 하드웨어 부분에 대한 비용 절감으로 이어짐) · 컴플렉스의 모든 구성 요소에 대한 오픈 소스 코드(제3자 독점 개발의 도움을 받지 않고 시스템 원칙을 독립적으로 변경하고 제품 라이센스 비용을 절감할 수 있음) · 시스템의 확장성 및 확장성(타사 및 독점 개발의 도움을 받지 않고 애플리케이션 범위를 확장하고 제품 라이선스 비용을 절감할 수 있음) · 진단 정보를 제공하는 표준 수단(시스템 유지 관리 비용을 절감할 수 있음) · 사용된 모든 소프트웨어 제품에 대한 자세한 문서의 가용성(신규 직원을 신속하게 교육할 수 있음) · 다른 제조업체의 장비로 작업할 수 있는 능력(하나의 소프트웨어 제품을 사용할 수 있게 함). (장비의 전체 목록은 부록 B를 참조하십시오). 일반적으로 프로젝트 개발에는 112시간(2주)이 소요되었습니다. 이 프로젝트의 구현에는 56시간(1주)이 소요됩니다. 1 프로젝트 개발 비용 계산 프로젝트 개발 비용은 다음으로 구성됩니다. · 급여 비용; · 장비 및 소프트웨어 제품의 감가상각비; · 전기 비용 지불; · 간접비. 급여 비용. 임금 비용을 계산할 때 우리는 이 프로젝트가 시스템 엔지니어라는 한 사람에 의해 개발되었음을 고려합니다. 이 지역에서 요구되는 수준의 시스템 엔지니어의 평균 시장 급여는 30,000루블입니다. 다음 데이터를 기반으로 엔지니어의 1시간 작업 비용을 계산해 보겠습니다. · 프리미엄 25%; · 지역 계수 15%; · 생산 달력에 따르면 2010년 노동 시간 자금은 1988시간입니다. 따라서 지역 계수를 고려한 비율은 다음과 같습니다. RF = 30,000 * 1.25 * 1.15 * 12/1988 = 260 루블 임금 비용을 계산할 때 발생한 임금에서 지불한 공제액이 고려됩니다. 즉, 보험료 요율의 총액은 다음을 포함하여 최대 UST 요율인 26%와 같습니다. · 연금 기금 - 20%; · FSSR - 2.9% · FFOMS - 1.1%; · GFOMS - 2%; · 사고에 대한 의무 사회 보험 - 0.2%. 총 공제액은 다음과 같습니다. CO = RF * 0.262 = 260 * 0.262 = 68 루블 엔지니어의 작업 시간(개발 112시간, 구현 56시간)을 고려하여 급여 비용을 계산합니다. ZP = (112 + 56) * (RF + CO) = 168 * 328 = 55104 루블 장비 및 소프트웨어 제품에 대한 감가상각비. 네트워크 프로젝트 개발 단계에서는 개인용 컴퓨터와 AQUARIUS SERVER T40 S41 서버를 주요 장비로 사용하였다. 현재 컴퓨터 비용은 약 17,000루블이고 서버는 30,000루블입니다. 따라서 장비에 대한 일회성 투자 비용은 다음과 같습니다. РВА = 47000 루블 컴퓨터와 서버의 수명 동안 현대화가 허용되며 이러한 유형의 비용도 계산에 고려됩니다. 현대화를 위해 RV의 50%를 배치합니다. РМА = РВ * 0.5 = 23500 루블 컴퓨터는 다음 단계에서 사용되었습니다. · 문헌 검색; · 네트워크 모니터링 시스템 설계를 위한 솔루션 검색; · 구조 및 하위 시스템 개발; · 네트워크 모니터링 시스템 설계; ·