두 데이터 센터 간에 대용량 데이터를 동기화하는 데 문제가 있습니다. 두 컴퓨터 모두 기가비트 연결이 있고 완전히 사용되지는 않았지만 얻을 수 있는 가장 빠른 속도는 6~10Mbit => 허용되지 않습니다!
어제 LEVEL3 라우터에 막대한 부하가 있음을 나타내는 일부 추적 경로를 만들었지만 문제는 현재 몇 주 동안 존재하며 높은 응답 시간이 사라졌습니다(300ms 대신 20ms).
실제 느린 노드를 찾기 위해 이를 어떻게 추적할 수 있나요? 더 큰 패키지를 포함하는 추적 경로를 생각했지만 이것이 작동할까요?
또한 다른 서버나 클라이언트에 대한 전송 속도가 훨씬 높기 때문에 이 문제는 우리 서버 중 하나와 관련이 없을 수도 있습니다. 실제로사무실 => 서버보다 빠르다서버 <=> 서버!
어떤 아이디어라도 감사하겠습니다;)
업데이트
실제로 ssh를 통한 rsync를 사용하여 파일을 복사합니다. 암호화에는 병목 현상이 더 많이 발생하는 경향이 있으므로 HTTP 요청을 시도했지만 불행하게도 속도도 마찬가지로 느립니다.
우리는 데이터 센터 중 하나와 SLA를 체결했습니다. 그들은 트래픽이 라우팅되는 값싼 네트워크와 관련이 있기 때문에 이미 라우팅을 변경하려고 시도했다고 말했습니다. "저렴한 네트워크"를 통해 라우팅된다는 것은 사실이지만 그 반대 방향일 뿐입니다. 우리의 방향은 LEVEL3을 통과하고 다른 방향은 (좋은 네트워크가 아니라고 말한) Lambdanet을 통과합니다. 내가 올바르게 이해했다면(저는 네트워크 중급자입니다) LEVEL3을 통해 라우팅을 강제하기 위해 더 긴 경로를 시뮬레이션하고 AS 경로에서 LEVEL3을 발표했습니다.
나는 기본적으로 그들이 옳은지 아니면 단지 책임을 포기하려고 하는지 알고 싶습니다. 문제는 문제가 양방향(경로는 다르지만)에 존재하므로 이는 호스팅 업체의 책임이라고 생각합니다. 그리고 솔직히 저는 몇 주 동안 600kb/s - 1.5MB/s만 처리할 수 있는 DC2DC 연결이 있다고 믿지 않습니다! 문제는 이 병목 현상이 어디에 있는지 감지하는 방법입니다.
답변1
공용 인터넷의 느린 링크를 통해 라우팅되는 경우 거의 유일한 옵션은 강제로 해당 링크를 우회하는 것입니다. 이를 수행하는 가장 간단한 방법은 두 끝점 간에 파일 전송을 시도하는 것입니다. 그 중 하나는 "지점 A"(데이터 원본)이고 다른 끝점은중간 사이트목적지인 "B지점"과 지리적으로 같은 위치에 있지 않습니다.
다음을 수행하는 서버인 "포인트 C"를 찾으면~ 아니다직면하고 있는 느린 인터넷 라우터를 통해 라우팅하려면 지점 A와 지점 C 사이에 VPN을 설정하여 트래픽이 느린 노드를 "주변으로 라우팅"할 수 있습니다.
비즈니스 가치가 높거나($$$$$$) ISP에 영향력이 있는 경우 레벨 3에 직접 문제를 제기할 수도 있습니다. 그러나 L3는 Tier 1 ISP이므로 서비스에 대한 불만 사항을 특별히 수용하지 않을 수 있습니다. 품질 또는 네트워크 포화 상태. 노드에서 경합을 생성하는 다운스트림 또는 기타 Tier 1 공급자와의 피어링 계약을 확장할 수 없거나 확장할 수 없거나 확장할 수 없는 경우 이에 대해 할 수 있는 일이 거의 없기 때문입니다.
"사무실에서 서버로" 링크가 더 빠르다고 말씀하셨기 때문에 적당히 성능이 좋은 컴퓨터(듀얼 코어 서버급 시스템이면 충분함)를 사용하여 "사무실" 사이트에서 VPN을 설정해 볼 수 있습니다.
아, 그것도!"지점 A"와 "지점 B" 사이의 대기 시간(종단 간)이 매우 높은 경우(서버 세계에서는 100ms 이상이 높은 경우) 다음 사항을 확인해야 합니다.당신은 수다스러운 네트워크 프로토콜을 사용하고 있지 않습니다. Samba(SMB 또는 Windows 파일 공유라고도 함)는극도로수다스러운; 다른 "동기화" 프로토콜도 수다스러울 수 있습니다.
Chatty 프로토콜은 데이터를 전송하기 위해 많은 동기식 "왕복" 왕복이 필요한 프로토콜입니다. 프로토콜이 너무 복잡하면 링크 속도에 관계없이 대기 시간만으로 전송에 병목 현상이 발생할 수 있습니다.
잡담이 실제로 처리량에 영향을 미치는지 확인하기 위해 할 수 있는 한 가지 방법은 알려진 방법을 사용하는 것입니다.수다스럽지 않은테스트 전송을 위한 HTTP와 같은 프로토콜입니다. 따라서 "느린" Level3 라우터를 통해 "지점 A"에서 "지점 B"까지 일반적인 기존 HTTP를 시도하고 대기 시간은 높지만 처리량은 여전히 양호하면알다 전송이 느린 이유는 프로토콜이 너무 수다스럽기 때문이므로 프로토콜을 변경해야 합니다.
그럼 간단하게 정의하고 설명하면서 논의를 마무리하겠습니다.세 가지 네트워크 장애그리고 왜누구나그들 중 이 문제에 대한 책임이 있을 수 있습니다.
지연 시간-- 데이터그램이 끝에서 다른 끝까지 도달하는 데 걸리는 시간입니다. 컴퓨터 중 하나가 너무 과부하되어 네트워킹 스택, 커널 또는 애플리케이션이 상당한 추가 대기 시간을 생성하지 않는 한 대부분의 경우 대기 시간을 직접적으로 개선할 수 없습니다. 공용 인터넷을 통한 대부분의 대기 시간은 컴퓨터나 엔드포인트가 아닌 인터넷 라우터에서 발생합니다.
대역폭-- 대역폭은 컴퓨터와 엔드포인트 간 가장 느린 링크의 최대 처리량입니다. 대부분의 최신 네트워크에서 대역폭은 실제 제한 사항이 아닙니다. 왜냐하면 대역폭이 실제 문제가 되기 훨씬 전에 다른 네트워크 장애가 설정되어 네트워크 속도를 저하시키기 때문입니다.
패킷 손실-- 패킷 손실이 증가할 수 있음인지된신뢰할 수 있는 데이터그램(예: TCP)에 대한 대기 시간이며, 버퍼가 이미 너무 가득 차서 TCP 전송 또는 수신 버퍼에서 패킷을 삭제해야 하는 링크의 포화 상태로 인해 발생하는 경우가 많습니다. 또한 거의 모든 TCP 패킷의 경우처럼 "시간에 민감한" 패킷의 경우 패킷 손실이 발생할 수 있습니다. 왜냐하면 패킷이 최종 기한 이후에 도착하면 폐기되기 때문입니다. 이는 더 큰 TCP 패킷이 여러 IP 데이터그램으로 조각화되고 수신 측의 TCP 프로토콜이 패킷 수신 중단을 결정하기 전에 모든 조각이 도착할 때까지 고정된 시간만 기다릴 수 있는 경우에 발생합니다. 따라서 패킷 손실은 포화 문제로 인해 간접적으로 파생됩니다.~이다대역폭 문제) 또는 하드웨어 문제나 오류로 인해 발생할 수도 있습니다.
근본적인 네트워크 장애에서 파생된 완화 방법은 근본적인 장애를 변경하지 않고 프로그램의 안정성을 향상시키기 위해 취할 수 있는 완화 방법입니다. 왜냐하면 대부분의 경우 이를 제어하기 위해 할 수 있는 일이 거의 또는 전혀 없기 때문입니다.
완화 방법 중 하나는 프로토콜을 덜 복잡하게 만드는 것입니다(또는 시스템 통합 관점에서사용현재 솔루션보다 덜 번거로운 기존 프로토콜). 엔드포인트 간에 데이터를 동기화하는 데 필요한 "왕복"이 적을수록 더 나은 결과를 얻을 수 있습니다. 일부 프로토콜은 가변적인 동기화 빈도를 요구하도록 설계될 수 있습니다. 이 경우 높은 대기 시간이나 패킷 손실이 감지되면 동적으로 동기화 빈도를 최대한 줄여야 합니다. 수다스러움을 줄이면 대기 시간과 패킷 손실을 완화하는 데 도움이 되지만 대역폭 한도 문제는 그렇지 않습니다.
두 번째 완화 방법은 현재 Fair Queue Controlled Delay AQM인 최상의 AQM(Active Queue Management) 알고리즘을 사용하도록 모든 홉(관리/하드웨어 수준에서 직접 제어하는 홉)을 구성하는 것입니다. 이는 Linux 커널 3.5 이상에서 fq_codelqdisc 구현으로 사용할 수 있으며 동적으로 수행됩니다.감소하다이러한 버퍼가 항상 생성하는 대기 시간을 줄이기 위해 전송 및 수신 버퍼의 크기를 조정합니다. 이렇게 하면 패킷 손실이 줄어들고 TCP 프로토콜을 사용하여 대기 시간에 대처하는 데 도움이 됩니다. 패킷이 링크를 통해 전송되기 전에 거쳐야 하는 대기 시간을 최소화하면 조각화된 패킷이 만료될 가능성이 줄어들기 때문입니다. 이 완화 조치는 노드가 "포화"된 경우(즉, TCP 버퍼가 비어 있으면 아무런 효과가 없는 경우)에만 차이가 있습니다. 네트워크 소켓에 데이터를 쓰는 속도가 업링크의 전송 속도를 초과할 때마다 노드가 포화됩니다. 이 상황에 대한 TCP 스택의 일반적인 대응은 버퍼를 더 크게 만드는 것입니다. 이는 실제로 부정적인 영향을 미칩니다. 지연 시간이 늘어나고 모든 종류의 문제가 발생하기 때문입니다. 따라서 fq_codel은 이를 완화하는 데 도움이 됩니다.
이 두 가지 완화 방법은 세 가지 근본적인 네트워크 장애를 모두 해결하는 데 도움이 됩니다.없이결함이 있는 노드 주위로 라우팅하고,없이하드웨어를 변경하거나 ISP에 문의하세요.