요약
- RFC 2391은 하나의 가상 주소가 서버 풀을 대표하게 했고, LSNAT는 각 새 세션마다 구성원을 선택한 뒤 이후 모든 패킷에 대해 변환 상태를 고정했다.
- 라운드 로빈, 세션 수, 트래픽, 가중치, 경로 비용, 핑은 결정 입력이었을 뿐 실제 애플리케이션 용량이나 성공을 증명하는 것은 아니었다.
- 호스트를 죽은 것으로 선언하면 새 할당은 멈출 수 있었지만, 이미 바인딩된 세션을 옮길 수는 없었다. 선택, 지속성, 장애 조치, 결과는 별개의 확인 기록이었다.
하나의 주소, 여러 가능한 장비
클라이언트 입장에서 확장 문제는 단순해 보였다. 수요는 서버 한 대가 편안히 처리할 수 있는 수준을 넘어 커졌다. 여러 서버가 같은 종류의 요청에 응답할 수 있었다. 용량이 바뀔 때마다 클라이언트가 새 프로토콜, 새 주소, 풀에 대한 지식을 가질 필요는 없어야 했다.
RFC 2391은 이러한 조건을 하나의 보이는 주소 뒤로 사라지게 하는 중개자를 제안했다. 그것은 RFC 1631의 주소 재작성과 새 세션을 위한 선택기를 결합했다. 가상 서버 주소는 한 대의 장비를 가리킬 수도 있고 집합을 가리킬 수도 있었다. 구성원은 LSNAT가 변경의 초점이 된 상태에서 추가, 제거, 교체될 수 있었다.
그 편의성은 권한을 옮겼다. 주소는 더 이상 작업을 수행할 장비를 지칭하지 않았다. 주소는 의사결정 과정으로 들어가는 입구를 지칭했다. LSNAT는 새 흐름을 해석하고 풀과 정책을 참조한 뒤 구성원을 선택하고, 선택된 서버가 패킷을 받도록 패킷을 변경했다.
이것은 RFC 1546이 설명한 애니캐스트 문제가 아니었다. 애니캐스트는 서비스 주소를 여러 인스턴스 중 하나로 라우팅 가능하게 했고, 연속된 데이터그램이 서로 다르게 선택될 수 있을 때 특히 어려움이 있었다. RFC 2391은 상태 기반 변환기를 삽입했다. 그것은 세션을 위해 서버를 선택한 뒤 그 선택을 기억해야 했다. 중심 질문은 단지 “이 패킷이 어느 인스턴스에 도달했는가?”가 아니라 “이 대화의 모든 패킷을 이제 어떤 저장된 연관이 통제하는가?”였다.
첫 선택이 패킷 경로 상태가 되었다
RFC 2391은 변환을 세 단계로 나눴다. 세션 바인딩 동안 들어오는 세션이 서버 주소와 연관되었다. 그 연관은 이후 모든 데이터그램의 변환 매개변수를 확립했다. 조회 및 변환 동안 후속 패킷은 저장된 세션과 대조되어 재작성되었다. 언바인딩 동안 세션이 끝난 것으로 간주되어 선택된 서버의 책임이 종료되었다.
따라서 바인딩은 라우팅 힌트 이상이었다. 클라이언트에서 서버로 가는 경로에서 변환기는 목적지 주소와 포트를 바꿀 수 있었다. 반환 경로에서는 클라이언트가 계속 가상 서비스를 보도록 소스 필드를 바꿀 수 있었다. IP 및 전송 체크섬은 변경을 따라가야 했다. 클라이언트는 교환이 중간에 새 엔드포인트를 관찰하지 않았다. 클라이언트는 변환기가 만들어낸 연속성을 관찰했다.
그 연속성은 경로 제약을 부과했다. 세션의 모든 요청과 응답은 동일한 LSNAT를 통과해야 했다. 한 방향이 그 상자를 우회하면 패킷은 일치하는 변환을 받지 못했다. 다른 변환기가 바인딩을 갖고 있지 않다면 광고된 가상 주소만으로 대화를 재구성할 수 없었다.
RFC의 직접적인 서술은 결정적이다. 세션이 호스트에 할당되면 끝날 때까지 다른 호스트로 이동할 수 없었다. 선택기는 수용 시점에 선택을 했다. 그것은 전송 상태, 애플리케이션 상태 또는 미완료 작업의 실시간 이전을 구현하지 않았다.
“최소 부하”는 모델이었지 진실에 대한 관찰이 아니었다
문서는 서버를 고르는 여러 방법을 탐구했다. 라운드 로빈은 저렴하고 눈먼 방식이었다. 부하를 전혀 검사하지 않았다. 최소 세션 방식은 각 구성원에 이미 할당된 바인딩을 세었다. 더 반응적으로 보였지만, 세션이 비슷한 자원을 소비하고 서버가 비슷한 능력을 가졌다고 가정할 때만 그랬다.
패킷이나 바이트를 세는 것은 또 다른 근사치를 제공했다. 트래픽을 덜 받는 서버가 여유 용량을 더 가질 수도 있고, 작은 요청을 받은 뒤 비싼 계산에 갇혀 있을 수도 있었다. 네트워크 볼륨은 LSNAT에서 관찰 가능했지만 CPU 압력, 메모리 경합, 디스크 지연, 애플리케이션 큐는 그렇지 않았다.
가중치는 운영자가 믿음을 부호화하게 했다. FTP 세션은 Telnet 세션보다 더 비싼 것으로 평가될 수 있었고, 한 장비는 다른 장비보다 더 강한 것으로 평가될 수 있었다. 산술은 더 표현력이 풍부해졌지만 그 입력은 여전히 추정이었다. 신중하게 계산된 잘못된 가중치는 여전히 잘못된 모델이었다.
RFC 2391은 그 한계를 공개적으로 인정했다. 원격 서버에서 사용되지 않는 용량에 대한 정확한 실시간 지식은 어려웠다. 변환기는 비침습적으로 추론할 수 있었고, 서버가 용량을 능동적으로 보고할 수도 있었다. 후자의 접근은 또 다른 프로토콜, 또 다른 타이밍 문제, 또 다른 낡거나 오해를 부르는 상태의 원천을 만들어야만 가시성을 개선했다.
분산 풀은 경로 비용을 추가했다. 선택기는 서버에 도달하는 비용을 할당된 세션이나 측정된 트래픽과 결합할 수 있었다. 도달할 수 없는 경로에는 무한 비용을 부여해 새 부하가 그리로 가지 않게 할 수 있었다. 그러나 경로 메트릭은 접근에 대한 근거로 남았고, 주소 뒤의 애플리케이션이 건강하다거나 이미 수락된 작업이 완료될 것이라는 근거는 아니었다.
선택 결정은 지역적이고 필연적으로 잠정적이었다. 그 입력은 “이 모델 아래에서 다음 세션은 어디로 가야 하는가?”에 답했다. 그 입력은 “어느 서버가 가장 많은 실제 용량을 보유하는가?”에 답하지 않았고, “이 사용자의 트랜잭션이 성공할 것인가?”에는 더더욱 답하지 않았다.
죽은 서버 규칙은 다음 세션을 보호했다
RFC 2391은 잘못된 선택의 최악 형태, 즉 더 이상 응답하지 않는 장비로 새 세션을 보내는 일에 주의했다. 그것은 휴리스틱 생존 확인을 제안했다. LSNAT는 풀 구성원에게 핑을 보낼 수 있었다. 새 세션을 할당한 뒤 구성원으로부터 오는 데이터그램을 감시할 수도 있었다. 몇 초 후 응답이 없으면 그 서버를 죽은 것으로 선언하고 새 세션 할당을 중단할 수 있었다.
회복조차 또 다른 실험으로 규정되었다. 잠시 후 선택기는 서버에 다시 새 세션을 주고 응답 시간을 관찰할 수 있었다. 구성원은 지역적 근거와 정책에 따라 자격 있음에서 자격 없음으로, 다시 그 반대로 이동했다. 핑 응답은 애플리케이션이 준비되었음을 증명하지 않았고, 애플리케이션 응답의 부재는 서버, 경로, 서비스, 요청 중 무엇이 잘못인지 식별하지 않았다.
그 한계는 RFC의 두 부분에서 나오며 흐려져서는 안 된다. 죽은 호스트 탐지는새할당을 멈췄다. 기존 세션은 끝나기 전에 이동할 수 없었다. 따라서 호스트가 수용 집합에서 제거되는 동안 그 호스트에 이미 바인딩된 모든 세션은 실패할 수 있었다. 풀의 여분 서버는 그러한 대화를 물려받지 않았다.
이것이 장애 회피와 장애 조치의 차이다. 회피는 다음 선택을 바꾼다. 장애 조치는 이미 진행 중인 작업에 필요한 상태를 보존하거나 재구성한다. RFC 2391은 전자를 설명했지, 후자의 투명한 구현을 설명하지 않았다.
RFC 3022는 나중에 같은 의존성을 변환기 계층에서 가시화했다. 하나의 NAT가 실패한 뒤 흐름을 재라우팅하는 것은 교체 장치가 구성과 세션 상태를 공유하지 않는 한 그 흐름 자체를 깨뜨릴 수 있었다. 옛 바인딩이 없는 새 경로는 같은 세션이 아니었다. RFC 3234는 결국 이것을 하드 상태로 분류했다. 복제된 사본이 없으면 실패는 연속이 아니라 재시작을 뜻했다.
세션을 끝내는 것도 또 다른 불확실한 결정이었다
바인딩은 영원히 남을 수 없었다. 변환기는 서버가 더 이상 책임지지 않을 때 바인딩을 해제해야 했다. TCP는 FIN과 RST 같은 가시적 신호를 제공했지만, 패킷 손실, 재전송, 재부팅은 여전히 중개자를 불확실하게 만들 수 있었다. UDP는 보편적인 세션 종료 메시지를 전달하지 않았다. 다른 프로토콜은 변환기의 세션 개념과 훨씬 더 멀어질 수 있었다.
그 결과는 휴리스틱 언바인딩이었다. 유휴 타이머는 애플리케이션이 잠시 조용했을 뿐인 매핑을 삭제할 수 있었다. 긴 타이머는 이미 사라진 대화의 상태를 보존할 수 있었다. RFC 2663은 나중에 그 문제를 정확히 서술했다. NAT의 세션은 애플리케이션의 세션과 다를 수 있으며, 오랜 침묵과 죽음을 구분하는 일반적으로 올바른 타임아웃은 없다.
이 불확실성은 언바인딩이 사무적 정리가 아니었기 때문에 중요했다. 그것은 향후 일치하는 패킷에 대해 누가 책임지는지 바꾸고 유한한 테이블 또는 포트 자원을 해제했다. 운영자는 경쟁하는 위험 아래 시간 초과를 선택했다. 연속성의 조기 상실 또는 낡은 상태의 축적이었다.
RFC 4787의 이후 UDP 매핑 타이머 요구 사항은 그 절충을 폐지하지 않았다. 그것들은 서로 다른 NAT 맥락을 위한 최소 동작을 표준화하면서 상당한 구현 차이를 문서화했다. 실행 중인 시스템은 여전히 관찰된 침묵이 언제 권한 삭제를 정당화하는지 결정해야 했다.
LS-NAPT는 더 많은 의존성으로 토폴로지 자유를 샀다
기본 LSNAT 토폴로지는 서버 풀을 경계 뒤에 두었고, 그곳에서 양방향이 자연스럽게 변환기를 지났다. RFC 2391은 또한 LS-NAPT를 설명했는데, 이것은 양쪽을 충분히 재작성해 클라이언트와 서버 트래픽을 강제로 그 상자를 다시 통과하게 했다. 서버는 더 이상 하나의 제한된 스텁 도메인 안에 있을 필요가 없었고, 접속 링크는 확장될 수 있었다.
대가는 명시적이었다. 더 많은 필드를 변환해야 했다. 그 구성에서 메커니즘은 TCP와 UDP에만 적용되었다. 사용 가능한 클라이언트 포트가 동시 세션의 상한을 부과했다. 설계는 중개자에서 상태, 처리, 주소-포트 의존성을 늘려 물리적 배치 제약을 완화했다.
이 절충은 미들박스의 특징이었다. 미들박스는 엔드포인트가 직접적이라고 생각하는 트래픽을 가로채고 재해석하기 때문에 엔드포인트를 바꾸지 않고도 유용한 동작을 배포할 수 있다. RFC 1631은 NAT에 대한 그 매력을 제시하면서 그 비용도 명명했다. 종단 간 의미가 주소 밖으로 나와 네트워크가 유지하는 상태로 이동했다.
RFC 7098은 나중에 세션이 완료될 때까지 한 서버에 머문다는 보장을 “지속성”이라는 용어로 불렀다. 그것은 최신 상태 기반 로드 밸런서가 첫 패킷 이후 튜플-서버 연관을 저장한다고 설명했다. 그 용어는 RFC 2391을 명확히 하지만, 확장되어서는 안 된다. 지속성은 안정적인 선택을 뜻하지 이동 가능한 선택을 뜻하지 않는다. 그것은 세션을 서버에 붙잡아 두지만, 서버가 살아남는다고 보장하지 않는다.
가상 주소는 첫 번째 확인 기록이었지 마지막이 아니었다
이제 증거 사슬을 압축 없이 서술할 수 있다. 가상 주소는 서비스 입구를 식별한다. 구성은 자격 있는 풀을 식별한다. 메트릭이나 보고서는 현재 조건의 부분적 시야를 제공한다. 정책은 구성원을 선택한다. 바인딩은 그 선택을 기록한다. 대칭적 통과와 변환이 그것을 보존한다. 서버 응답은 일부 실행 중 동작을 보여준다. 오직 애플리케이션 결과만이 의도한 작업이 발생했는지 보여준다.
어떤 이전 계층도 이후 계층을 사칭할 수 없다. 구성된 구성원이 반드시 살아 있는 것은 아니다. 살아 있는 호스트가 반드시 준비된 것은 아니다. 부하가 적은 서버가 반드시 권한이 있거나 올바른 것은 아니다. 바인딩은 완료된 요청이 아니다. 안정적인 패킷 경로는 성공한 애플리케이션 세션이 아니다.
Lu Heng의 노트는 이것을 현실 계층의 규율이라고 설명한다. 명세나 기록은 의미를 조정할 수 있지만, 그것이 서술하는 실행 상태를 창조하지는 않는다. RFC 2391은 중개자가 하나의 주소를 단순해 보이게 만들도록 구축되었기 때문에 유용한 역사적 사례다. 그럼에도 그 자체의 텍스트는 더 어려운 진실을 보존했다. 겉보기 엔드포인트는 지역적 선택, 유지된 상태, 강제된 통과, 불완전한 관찰에 의존했다.
풀은 다음 도착을 위해 대안을 제공할 수 있었다. 그러나 이미 확립된 대화를 대체 가능한 작업으로 바꿀 수는 없었다. RFC 2391에서 가장 중요한 문장은 부하 분산 공식이 아니었다. 바인딩이었다. 선택이 상태가 되는 순간, “다른 건강한 서버가 존재한다”는 것은 더 이상 복구 계획이 아니었다.
출처
- RFC 2391 — IP 네트워크 주소 변환을 이용한 부하 분산
- RFC 2391에 대한 RFC Editor 기록
- RFC 2391에 대한 IETF Datatracker 이력
- RFC 2391에 대한 RFC Editor 정오표 검색
- RFC 1631 — IP 네트워크 주소 변환기
- RFC 1794 — 부하 분산을 위한 DNS 지원
- RFC 2663 — IP 네트워크 주소 변환기 용어와 고려 사항
- RFC 3022 — 전통적 IP 네트워크 주소 변환기
- RFC 3234 — 미들박스: 분류와 쟁점
- RFC 4787 — 유니캐스트 UDP를 위한 네트워크 주소 변환 동작 요구 사항
- RFC 5382 — TCP를 위한 NAT 동작 요구 사항
- RFC 7098 — 서버 팜의 부하 분산을 위한 IPv6 플로 레이블 사용
- Lu Heng — 실행 코드 우선성
- Lu Heng — 최소 초기 명세, 지역화된 미래 결정, 자발적 채택
- Lu Heng — 현실 계층, 상징적 권력, 그리고 명확성
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





