투명한 프로세스 간 통신
Transparent Inter-process Communication
TIPC(Transparent Inter Process Communication)는 클러스터 전체 작업을 위해 설계된 Linux의 프로세스 간 통신(IPC) 서비스입니다.잘 알려진 Unix 도메인 소켓 서비스와 대조적으로 클러스터 도메인 소켓으로 표시되는 경우가 있습니다. 클러스터 도메인 소켓은 단일 커널에서만 작동합니다.
| 인터넷 프로토콜 스위트 |
|---|
| 응용 프로그램레이어 |
| 트랜스포트 레이어 |
| 인터넷 레이어 |
| 링크 레이어 |
특징들
TIPC의 일부 기능:
- 서비스 주소 지정 - 소켓이 아닌 서비스 주소 지정
- 서비스 트래킹 - 소켓에 대한 서비스 주소 바인딩/언바인딩 서브스크라이브
- 클러스터 전체 IPC 서비스 - 서비스 위치가 발신인에게 투과적임
- 유니캐스트, 애니캐스트 및 멀티캐스트를 사용한 데이터그램 메시징 - 신뢰할 수 없는 전달
- 커넥션 지향 메시징 - 신뢰성 높은 전달
- 그룹 메시징 - 신뢰성 높은 전달을 통한 데이터그램 메시징
- 클러스터 토폴로지 추적 - 추가/손실 클러스터 노드 등록
- 접속 추적 - 노드 간 개별 링크 업/다운 등록
- 새로운 클러스터 노드 자동 검출
- 2단계의 장애 검출로 최대 1000노드까지 확장 가능
- 매우 뛰어난 퍼포먼스
- kernel.org에서 인트리 커널 모듈로 구현
실장
TIPC 프로토콜은 주류 Linux 커널에서 모듈로 제공되므로 대부분의 Linux 배포판에서 사용할 수 있습니다.TIPC 프로젝트는 또한 Wind River의 VxWorks 및 Sun Microsystems의 Solaris를 포함한 다른 운영 체제에 대한 프로토콜의 오픈 소스 구현을 제공합니다.TIPC 어플리케이션은 일반적으로 C(또는 C++)로 작성되며 AF_의 소켓을 사용합니다.TIPC 주소 패밀리Go, D, Perl, Python, Ruby 지원도 가능합니다.
서비스 주소 지정
TIPC 어플리케이션에서는, 3 종류의 주소를 사용할 수 있습니다.
- 서비스 주소이 주소 유형은 32비트서비스 유형 ID와 32비트서비스 인스턴스 ID로 구성됩니다.유형 식별자는 일반적으로 사용자 애플리케이션프로그래머에 의해 결정되어 하드코딩되지만 그 값은 같은 클러스터에 존재할 수 있는 다른 애플리케이션과 조정되어야 할 수 있습니다.인스턴스 식별자는 종종 응용 프로그램별 기준에 따라 프로그램에 의해 계산됩니다.
- 서비스 범위이 주소 유형은 동일한 유형의 서비스 주소의 범위를 나타내며, 인스턴스는 하한과 상한 사이의 범위입니다.소켓을 이 주소 유형에 바인딩함으로써 많은 인스턴스를 나타낼 수 있으며, 이는 많은 경우에 유용한 것으로 판명되었습니다.
- 소켓 어드레스이 주소는 클러스터의 특정 소켓에 대한 참조입니다.여기에는 32비트 포트 번호와 32비트 노드 번호가 포함됩니다.포트 번호는 소켓이 생성될 때 시스템에 의해 생성되며 노드 번호는 구성에 의해 설정되거나 Linux 4.17에서 대응하는 노드 ID에서 생성됩니다.이 타입의 주소는 서비스 주소와 같은 방법으로 접속 또는 메시지 전송에 사용할 수 있지만 참조 소켓이 존재하는 한에만 유효합니다.
서로 다른 소켓을 동일한 서비스 주소 또는 범위에 바인딩할 수 있는 것처럼 소켓을 여러 다른 서비스 주소 또는 범위에 바인딩할 수 있습니다.바인딩은 가시성 범위(노드 로컬 또는 클러스터 글로벌 가시성)에서도 검증됩니다.
데이터그램 메시징
데이터그램 메시지는 1 ~66,000 바이트 길이의 개별 데이터 단위로, 연결되지 않은 소켓 간에 전송됩니다.UDP와 마찬가지로 TIPC 데이터그램이 목적지에 도달하는 것은 보장되지 않지만 전달될 가능성은 여전히 전자보다 훨씬 높습니다.링크 레이어 전달 보증을 위해 데이터그램 전달의 유일한 제한 요소는 소켓 수신 버퍼 크기입니다.송신자의 소켓에 적절한 전송 중요도를 부여함으로써, 성공 가능성을 높일 수도 있습니다.데이터그램은 세 가지 방법으로 전송할 수 있습니다.
- 유니캐스트소켓 주소가 지정되어 있는 경우는, 메세지가 그 소켓에 송신됩니다.TIPC에서는 유니캐스트라는 용어는 이 어드레싱 모드를 나타내기 위해 예약되어 있습니다.
- 애니캐스트.서비스 주소를 사용하면, 복수의 일치하는 행선지가 있는 경우가 있습니다.전송 방식은, 애니 캐스트라고 불리는 것이 됩니다.즉, 일치하는 행선지 중 하나가 선택될 가능성이 있습니다.서비스 주소에서 소켓주소로 변환되는 내부 함수는 라운드 로빈 알고리즘을 사용하여 수신처 간의 부하 바이어스 위험을 줄입니다.
- 멀티 캐스트서비스 범위 주소 유형은 멀티캐스트주소이기도 합니다.응용 프로그램이 서비스 범위를 수신인 주소로 지정하면 메시지 복사본이 클러스터 내의 일치하는 모든 소켓으로 전송됩니다.지정된 멀티캐스트 범위 내의 일치하는 서비스인스턴스에 바인드된 소켓은 메시지의 복사본을 1개 받습니다.TIPC 멀티캐스트는 가능한 한 UDP 멀티캐스트 또는 이더넷브로드캐스트를 사용합니다.
커넥션 지향 메시징
접속은 SOCK_STREAM 소켓에서 accept() 및 connect()를 사용하여 TCP와 같은 방법으로 확립할 수 있습니다.단, TIPC에서는 클라이언트와 서버는 포트 번호와 IP 주소 대신 서비스 주소 또는 범위를 사용합니다.또한 TIPC는 이 표준 설정 시나리오에 대한 두 가지 대안을 제공합니다.
- 소켓은 SOCK_SEQPACKET으로 작성할 수 있습니다.이는 데이터 교환이 최대 66,000바이트의 메시지로 이루어져야 함을 의미합니다.
- 클라이언트는 수신 소켓에 데이터 메시지를 보내는 것만으로 접속을 초기화할 수 있다.마찬가지로 생성된 서버 소켓은 연결을 완료하기 위해 클라이언트에 데이터 메시지로 응답할 수 있습니다.이와 같이 TIPC는 암시적인 0-RTT 접속 셋업 메커니즘(특히 많은 경우 시간을 절약할 수 있습니다)을 제공합니다.
TIPC 접속의 가장 큰 특징은 액티브한 네이버하트비팅에 의존하지 않고 피어 소켓과의 접속 끊김에 신속하게 반응할 수 있다는 것입니다.
- 소켓이 사용자에 의해 또는 프로세스 크래시에 의해 무의식적으로 닫히면 커널 소켓 청소 코드는 FIN/ERROR 메시지를 피어에 발행합니다.
- 클러스터 노드와의 접속이 끊어지면 로컬링크 계층은 해당 노드에 접속되어 있는 모든 소켓에 FIN/ERROR 메시지를 발행합니다.피어 노드의 장애 검출 시간은 최대 50 밀리초까지 설정할 수 있습니다.기본값은 1,500 밀리초입니다.
그룹 메시징
그룹 메시징은 위에서 설명한 바와 같이 데이터그램메시징과 비슷하지만 엔드 투 엔드 흐름 제어를 통해 전달 보증이 제공됩니다.그러나 몇 가지 눈에 띄는 차이점이 있다.
- 메시징은 닫힌 멤버소켓 그룹 내에서만 실행할 수 있습니다.
- 소켓은 서비스 주소를 사용하여 그룹에 가입합니다.여기서 type 필드는 그룹 ID를 나타내고 instance 필드는 멤버 ID를 나타냅니다.따라서 멤버는 1개의 서비스 주소에만 바인드할 수 있습니다.
- 애니캐스트 메시지를 보낼 때 룩업알고리즘은 일반 라운드 로빈알고리즘을 적용하지만 잠재적인 리시버 상의 현재 부하(애드버타이즈된 송신창 등)도 고려하여 선택합니다.
- 멀티캐스트는 범위가 아닌 서비스 주소로 실행되므로 전송된 메시지의 복사본은 정확히 해당 주소를 사용하여 그룹에 가입한 모든 멤버에게 도달합니다.
- 멤버 ID를 고려하지 않고 모든 그룹 멤버에게 메시지를 전송하는 그룹 브로드캐스트모드가 있어요
- 메시지 시퀀셜리티는 전송 모드 사이에서도 보증됩니다.
그룹에 가입할 때 멤버는 그룹의 다른 멤버에 대해 가입 이벤트를 수신할지 탈퇴할지를 지정할 수 있습니다.이 기능은 서비스 트래킹 기능을 활용하여 그룹 구성원은 적절한 멤버소켓으로 이벤트를 수신합니다.
서비스 추적
애플리케이션은 예약된 서비스 주소를 사용하여 TIPC 내부 토폴로지 서버에 대한 접속을 열어 추적 서비스에 액세스한다.그런 다음 추적하는 서비스 주소 또는 범위를 나타내는1 개 이상의 서비스 서브스크립션메시지를 트래킹서비스로 송신할 수 있습니다.이에 대해 토폴로지 서비스는 일치하는 주소가 클러스터 내의 소켓에 의해 바인드 또는 바인드될 때마다 서비스 이벤트 메시지를 응용 프로그램에 반환합니다.서비스 이벤트에는 일치하는 서비스 범위와 바인드/언바인드 소켓의 포트 및 노드 번호가 포함됩니다.서비스 추적에는 다음 두 가지 특별한 사례가 있습니다.
- 클러스터 토폴로지 트래킹TIPC는 다른 노드와의 접속을 확립하면 예약된 서비스 유형을 사용하여 내부적으로 서비스 바인딩 테이블에 노드 로컬바인딩을 만듭니다.이것에 의해, 노드상의 애플리케이션은 언제라도 도달 가능한 피어 노드를 추적할 수 있습니다.
- 클러스터 접속 트래킹TIPC는 다른 노드에 대한 새로운 링크를 확립할 때 예약된 서비스 유형을 사용하여 노드의 바인딩 테이블에 노드 로컬바인딩을 내부적으로 만듭니다.이것에 의해, 노드상의 애플리케이션은 언제라도 피어 노드에의 모든 동작중의 링크를 추적할 수 있습니다.
대부분의 서비스 서브스크립션은 노드 로컬토폴로지 서버를 대상으로 하지만 다른 노드의 서버에 대한 연결을 확립하고 로컬바인딩을 감시할 수 있습니다.예를 들어 접속 가입자가 로컬노드에서 볼 수 있는 것에 한정되지 않고 클러스터 전체에서 모든 접속의 매트릭스를 작성하려고 하는 경우에 도움이 될 수 있습니다.
클러스터
TIPC 네트워크는 개별 처리 요소 또는 노드로 구성됩니다.노드는 물리적 프로세서, 가상 시스템 또는 네트워크 네임스페이스(예: Docker Containers) 중 하나입니다.이러한 노드는 할당된 클러스터 ID에 따라 클러스터로 배열됩니다.클러스터 ID가 같은 모든 노드는 상호 네이버 검출이 가능하도록 네트워크가 설정되어 있는 경우 서로 링크를 확립합니다.클러스터 ID를 기본값에서 변경하면 서로 다른 클러스터 내의 노드가 서로 검출될 가능성이 있는 경우(예를 들어 동일한 서브넷에 연결되어 있는 경우)에만 변경할 수 있습니다.다른 클러스터의 노드는 TIPC를 사용하여 서로 통신할 수 없습니다.
Linux 4.17보다 이전 버전에서는 노드가 고유한 32비트 노드 번호 또는 주소를 구성해야 합니다. 이러한 번호는 특정 제한 사항을 준수해야 합니다.Linux 4.17 이후 각 노드에는 128비트 노드 ID가 있으며 노드 클러스터 내에서 고유해야 합니다.다음으로 노드번호는 그 ID에서 보증된 일의 해시로서 계산됩니다.
노드가 클러스터의 일부인 경우 사용자는 노드의 자동 구성 기능을 사용할 수 있습니다.이 기능은 첫 번째 인터페이스가 연결되었을 때 ID가 생성되며 노드의 호스트 이름이나 UUID에서 ID를 명시적으로 설정할 수 있습니다.노드가 클러스터의 일부가 아닌 경우 해당 노드의 ID는 기본값인 0으로 유지될 수 있습니다.
네이버 검출은 UDP 멀티캐스트 또는 L2 브로드캐스트(사용 가능한 경우)에 의해 실행됩니다.인프라스트럭처에서 브로드캐스트/멀티캐스트 지원이 없는 경우 명시적으로 설정된IP 주소로 검출을 실행할 수 있습니다.
노드간 링크
클러스터는 하나 또는 두 개의 링크로 상호 연결된 노드로 구성됩니다.링크는 신뢰할 수 있는 패킷 전송 서비스를 구성하며, "L2.5" 데이터 링크 계층이라고도 합니다.
- 이것에 의해, 모든 패킷의 전달과 시퀀셜이 보증됩니다.
- 노드간 접속의 트렁크로서 기능해, 그것들을 추적합니다.
- 피어 노드에 대한 모든 컨택이 상실되면 해당 피어에 대한 접속이 있는 소켓이 통지되므로 연결이 끊어질 수 있습니다.
- 각 엔드포인트는 서비스 바인딩 테이블의 로컬 복제본에서 피어 노드의 주소 바인딩을 추적합니다.
- 피어 노드에 대한 컨택이 상실되면 해당 피어로부터의 모든 바인딩이 삭제되고 일치하는 모든 서브스크라이버에게 서비스 트래킹이벤트가 발행됩니다.
- 통상의 데이터 패킷트래픽이 없는 경우, 각 링크는 프로브/하트비트에 의해서 액티브하게 감시됩니다.
- Failure Detection Tolerance는 50밀리초에서 30초까지 설정할 수 있습니다.기본 설정은 1.5초입니다.
- 퍼포먼스와 용장성을 위해 노드쌍당2개의 링크를 별도의 네트워크인터페이스에 확립할 수 있습니다.
- 링크 페어는 로드 쉐어링 또는 액티브 스탠바이용으로 설정할 수 있습니다.
- 링크에 장애가 발생했을 경우 나머지 링크에 대한 장애 없는 페일오버가 발생합니다.
클러스터 확장성
Linux 4.7 이후 TIPC는 독자적인 특허 출원 중인 자동 적응 계층형 네이버 모니터링 알고리즘을 갖추고 있습니다.이 오버랩링 모니터링 알고리즘은 실제로는 링 모니터링과 가십 프로토콜을 조합하여 1.5초의 장애 검출 시간으로 최대 1000노드로 이루어진 풀 메쉬 클러스터를 확립할 수 있으며, 소규모 클러스터에서는 훨씬 짧은 시간이 가능합니다.
성능
TIPC는 특히 라운드 트립 지연 시간에 관해 탁월한 성능을 제공합니다.노드간에서는 일반적으로 TCP보다 33%, 노드내에서는 작은 메시지의 경우 2배, 큰 메시지의 경우 7배 빠릅니다.노드간에서는 TCP보다 최대 스루풋이 10~30% 낮은 반면 노드내 스루풋은 25~30% 높아집니다.TIPC 팀은 현재 노드 내 메시징에 GSO/GRO 지원을 추가하는 방법을 연구 중이며, 여기서도 TCP와 일치시킬 수 있습니다.
미디어 전송
모든 종류의 전송 미디어를 사용할 수 있도록 설계되었지만 2018년 5월[update] 현재 구현은 UDP, 이더넷 및 InfiniBand를 지원합니다.VxWorks 구현은 동일한 하드웨어에서 동시에 실행되는 운영 체제의 여러 인스턴스에서 액세스할 수 있는 공유 메모리도 지원합니다.
보안.
보안은 현재 TIPC를 운반하는 운송 매체에 의해 제공되어야 합니다.UDP 경유로 동작하는 경우는 IPSec을 사용할 수 있습니다.이더넷에서는 MACSec이 최선의 옵션입니다.TIPC 팀은 현재 TLS 또는 DTLS를 네이티브로 지원하거나 OpenSSL에 추가하는 방법을 검토하고 있습니다.
역사
이 프로토콜은 원래 1996-2005년 에릭슨에서 Jon Paul Maloy에 의해 개발되었으며, 이후 오픈 소스 커뮤니티에 공개되어 메인스트림 Linux 커널에 통합되기 전까지 수년간 클러스터 애플리케이션에서 사용되었습니다.이후 수많은 개선과 업그레이드를 거쳤으며, 모두 다양한 회사의 참가자들과 함께 전담 TIPC 프로젝트 팀에 의해 수행되었습니다.TIPC용 관리툴은 모든 Linux 디스트리뷰션에서 표준으로 제공되는 iproute2 툴 패키지의 일부입니다.
