![호스팅된 네트워크 대기 시간](https://rvso.com/image/617261/%ED%98%B8%EC%8A%A4%ED%8C%85%EB%90%9C%20%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC%20%EB%8C%80%EA%B8%B0%20%EC%8B%9C%EA%B0%84.png)
배경
전용 방화벽(Cisco ASA 5505 Sec+) 뒤에 새로운 호스팅 전용 데이터베이스 서버가 있습니다. 계획은 백엔드 DB 서버에 다시 연결하는 방화벽 반대편에 가상("클라우드"라고도 함) 웹 서버 또는 두 개를 두는 것입니다.
서버를 설정하는 동안 나는 서버의 네트워크 성능에 깊은 인상을 받지 못했습니다. 2개의 서버에는 GigE가 있지만(방화벽은 100Mb만 지원하므로) 제가 겪었던 대부분의 성능 문제는 이것으로 적절하게 설명될 수 있습니다.
문제
그러나 문제 해결의 일환으로 전용 서버에서 방화벽으로 일련의 핑을 실행했습니다. 이러한 핑은 몇 가지 흥미로운 결과로 돌아왔습니다. 특히 100개의 핑 분포는 다음과 같습니다.
57% < 1ms
14% between 1ms and 2ms
12% between 2ms and 3ms
11% between 3ms and 6ms
6% >= 6ms
Min/Avg/Max: 0/1/8 ms
나는 첫 번째 홉이 지속적으로 1ms 미만일 것으로 예상했습니다(그리고 그렇지 않은 하드 배선 환경을 솔직히 기억할 수는 없습니다). 후속 테스트는 매우 유사했으며 며칠 동안 진행되었으므로 이것은 고립된 사건으로 보이지 않습니다. 재전송 또는 삭제된 패킷이 관찰되지 않았습니다. 방화벽을 통한 핑(Ping)도 비슷한 성능을 보여줍니다.
58% < 1ms
14% between 1ms and 2ms
8% between 2ms and 2ms
14% between 3ms and 6ms
6% >= 6ms
Min/Avg/Max: 0/2/56 ms
문제 해결
호스팅 업체가 서버, 방화벽 및 중간 스위치를 검사한 결과 아무런 문제도 발견되지 않았습니다. 그들은 또한 네트워크에서 ICMP 트래픽의 "우선순위를 낮춘다"고 지적합니다. 그들은 최근 일부 포트 플래핑(서버 구성으로 인해 발생했을 가능성이 있음)을 발견했으며 상황을 "계속 모니터링"할 것입니다. 포트 플래핑은 핑 시간을 설명할 만큼 충분히 많지 않거나 시간 상관 관계가 없지만 근본적인 문제의 (다른) 증상일 수도 있습니다.
ASA에 직접 액세스할 수는 없지만 호스팅 업체는 문제 해결의 일환으로 ASA에 대한 몇 가지 통계를 실행했습니다.
# ping ***** (series of 5-packet pings from firewall to server, edited for brevity)
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/10 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/10 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/8/10 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/6/10 ms
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
# show cpu usage
CPU utilization for 5 seconds = 13%; 1 minute: 11%; 5 minutes: 10%
# show mem
Free memory: 341383104 bytes (64%)
Used memory: 195487808 bytes (36%)
------------- ----------------
Total memory: 536870912 bytes (100%)
# show int eth0/1
Interface Ethernet0/1 "", is up, line protocol is up
Hardware is 88E6095, BW 100 Mbps, DLY 100 usec
Full-Duplex(Full-duplex), 100 Mbps(100 Mbps)
Available but not configured via nameif
MAC address *****, MTU not set
IP address unassigned
5068644 packets input, 5077178693 bytes, 0 no buffer
Received 4390 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 L2 decode drops
387883 switch ingress policy drops
3220647 packets output, 1648213382 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collisions, 0 deferred
0 lost carrier, 0 no carrier
0 input reset drops, 0 output reset drops
0 rate limit drops
0 switch egress policy drops
ACL이 몇 개 있고 RDP 세션이 통과할 가능성이 있는 방화벽의 CPU 사용량이 겉으로 보기에 높은 것 외에는 ASA 통계에 대해 경고할만한 내용이 없습니다. 확실히 과세된 IMHO는 아닌 것 같습니다.
질문
디스크 검색 시간이 다가오고 있고 아직 방화벽이나 서버에 프로덕션 트래픽이 없다는 점을 고려하면 여전히 약간 걱정됩니다. 여러분은 어떻게 생각하시나요? 이것이 문제입니까? 대규모 데이터 센터 환경에서는 이것이 정상입니까?
답변1
우선, 보유하고 있는 특정 ASA 모델이나 라이선싱 모드를 밝히지 않았습니다. "sh ver" 및 "sh int Ethernet0/0"의 출력을 게시해 주세요.
즉, ASA 모델마다 처리량 제한이 다릅니다. 예를 들어 ASA5510의 최대 처리량(동시) 제한은 300mbps입니다. 보다http://www.cisco.com/en/US/prod/coltral/vpndevc/ps6032/ps6094/ps6120/product_data_sheet0900aecd802930c5.html전체 목록을 보려면.
대기 시간과 관련하여 모든 Cisco 제품은 최하위 대기열의 장치에 직접 트래픽을 배치합니다. 결과를 예측할 수 없기 때문에 라우터나 방화벽에 대해 ICMP 에코를 수행하는 것은 나쁜 습관입니다. 여기에는 2개의 ASA5510(모두 기가비트)과 2개의 3750-X 스위치가 있으며, 트래픽이 많이 발생하면 모두 최대 300ms의 ICMP 에코 대기 시간으로 점프합니다.
이는 라우팅/전달된 트래픽이 느리다는 의미는 아닙니다.
대기 시간을 확인하려면 ASA 전체에서 장치 간 ping을 사용하십시오. 유일하게 믿을 수 있는 방법입니다.