최적의 네트워크 구성으로 MinIO를 최대한 활용하세요 - 방법은 다음과 같습니다.

MinIO는 둘 이상의 물리적 또는 가상 머신의 컴퓨팅 및 스토리지 리소스를 효율적으로 사용하는 분산 방식으로 배포될 수 있습니다. 이는 Amazon Web Services, Google Cloud Platform, Microsoft의 Azure 플랫폼 등과 같은 프라이빗 또는 퍼블릭 클라우드 환경에서 실행되는 MinIO일 수 있습니다. MinIO는 여러 유형의 토폴로지에 배포할 수 있습니다. 프로덕션에서는 MNMD( Multi-Node Multi-Drive ) 배포를 권장합니다. MinIO는 사용 사례에 맞게 설계하고 최적화할 수 있는 단일 사이트 배포에 대한 BC/DR 등급 장애 조치 및 복구 지원을 제공하기 위해 사이트 복제를 권장합니다.

이전 블로그 게시물에서 MinIO 배포를 위한 하드웨어를 선택할 때 사용할 몇 가지 모범 사례에 대해 이미 논의했습니다. 우리는 최고의 지역 선택, 올바른 드라이브, CPU 및 메모리 구성, 심지어 일부 권장 네트워크 구성까지 하드웨어의 다양한 측면을 다루었습니다. 우리는 시스템 설계에 대한 다양한 모범 사례를 다루었지만 언제든지 더 깊이 들어갈 수 있습니다. 오늘은 드라이브와 네트워크에서 최고의 성능을 얻기 위해 MinIO 설계와 관련된 몇 가지 세부 사항을 살펴보겠습니다.

이 블로그 게시물에서는 여러 MinIO 배포에서 데이터가 효율적으로 저장되고 액세스되도록 하는 데 사용할 수 있는 다양한 복제 전략 및 네트워크 토폴로지로 MinIO를 구성할 수 있는 네트워크 구성에 대해 자세히 설명합니다. 본딩/이중 NIC 설정(추가 오버헤드 추가)과 같은 복잡한 구성을 수행할 필요가 없습니다.

간단한 네트워킹 전략

MinIO는 클라우드 네이티브 서비스를 위한 S3 호환 스토리지 백엔드입니다. 일반적으로 네트워크 트래픽은 앱과 클러스터 간 또는 클러스터의 노드 간으로 간주됩니다. 노드 간 트래픽으로 인해 노드 간 네트워킹이 최대한 빠른 것이 가장 중요합니다. 각 풀은 자체 삭제 세트가 있는 독립적인 노드 그룹으로 구성됩니다. MinIO는 각 풀에 쿼리하여 읽기 및 쓰기 작업을 지시하는 올바른 삭제 세트를 결정해야 합니다. 따라서 각 추가 풀은 호출당 노드 간 트래픽을 최소화하지만 증가시킵니다. 그러면 올바른 삭제 세트가 포함된 풀이 작업에 응답하고 애플리케이션에 완전히 투명한 상태를 유지합니다.

기업이 1GbE 또는 10GbE NIC로 성공할 수 있는 시대는 지났습니다. 현대 기업 워크로드는 100GbE NIC를 이상적으로 활용합니다. TCP 프로토콜의 물리적 한계와 오버헤드를 고려할 때 이러한 NIC는 사용 가능한 대역폭의 80-90%를 제공할 것으로 예상됩니다. 일반적으로 100Gbps NIC의 경우 약 10GB/s, 제대로 프로비저닝된 네트워크에서는 최대 12GB/s입니다. MinIO는 모든 인터페이스에서 수신 대기하면서 모든 대역폭을 활용하기 위해 별도의 추가 네트워킹 구성이 필요하지 않습니다. 기본적으로 MinIO는 여러 네트워크 인터페이스(NIC)에서 수신 대기를 지원합니다.

MinIO 네트워킹에는 다른 특별한 구성이 필요하지 않지만 선택적으로 앞서 논의한 네트워킹 기본 사항 중 일부를 사용하여 특정 인터페이스를 통해 MinIO 트래픽을 라우팅할 수 있습니다.

이 예에서는 Linux 운영 체제를 사용하여 시연하지만 네트워킹 기본 사항은 사용하는 OS에 관계없이 동일합니다. 구현은 네트워크 구성에 따라 약간 다를 수 있지만 이를 통해 아이디어를 얻을 수 있습니다.

먼저 경로 테이블을 나열하는 것부터 시작하겠습니다.

 $ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.18

MinIO 서버를 10.56.98.16/28 CIDR 범위 내에 있도록 구성한 경우 MinIO 노드의 IP 주소 중 하나가 10.56.98.21이라고 가정해 보겠습니다. 이는 /28이 10.56의 경로 테이블 항목과 일치하기 때문에 eth0 인터페이스를 통해 라우팅됩니다. .98.0/24.

그러나 MinIO 트래픽을 eth0이 아닌 eth1을 통해 라우팅하려면 해당 서브넷과 일치하는 모든 트래픽이 해당 특정 네트워크 인터페이스를 통해 라우팅되도록 MinIO CIDR에 대한 특정 경로를 추가해야 합니다.

 $ ip route add 10.56.98.16/28 dev eth1

경로가 추가되면 라우팅 테이블을 다시 나열하여 어떻게 보이는지 살펴보겠습니다.

 $ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.33.18 10.56.98.16/28 dev eth1 scope link

이제 /28 CIDR에 대한 경로가 표시됩니다. MinIO 노드 10.56.98.21을 핑하면 이제 eth1 인터페이스를 통해 라우팅됩니다. 이는 /24가 /28과 겹치는 두 개의 경로가 있는 경우 일반적으로 접두사가 가장 긴 경로에 우선 순위가 부여되고(이 경우 /28) 트래픽을 라우팅할 때 다른 짧은 접두사 경로보다 우선 적용되기 때문입니다. 이를 최장 일치 접두사 규칙이라고 합니다.

10.56.98.21에 ping을 실행한 후 아래와 같이 tcpdump를 확인하면 10.56.98.16/28의 트래픽이 적절하게 라우팅되고 있는지 확인할 수 있습니다. 소스 10.56.98.18의 트래픽이 eth1을 통해 10.56.98.21로 라우팅되는 것을 확인할 수 있습니다.

 $ tcpdump -n -i eth1 icmp … 15:55:44.410450 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 123, length 64 15:55:44.410471 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 123, length 64 15:55:45.434489 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 124, length 64 15:55:45.434518 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 124, length 64 15:55:46.458490 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 125, length 64 15:55:46.458520 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 125, length 64

MinIO에서 볼 수 있듯이 트래픽 분리를 달성하는 데 필요한 추가 특수 포트나 서비스가 없습니다. MinIO는 단순성을 염두에 두고 설계되었으며 이 경우 게이트웨이 서비스와 같은 복잡한 것을 설계하기보다는 항상 구축과 구매를 고려하고 있습니다. MinIO는 OS 계층에서 이미 사용 가능한 네트워킹 기본 사항을 활용하여 최소한의 오버헤드로 동일한 결과를 달성합니다. 가능한.

우리는 이 아이디어를 한 단계 더 발전시킬 수 있습니다. 요즘 서버에는 인터페이스를 2개 이상 추가할 수 있는 옵션이 있습니다. 따라서 애플리케이션 트래픽이 MinIO와 동일한 인터페이스를 거치는 대신 별도의 CIDR 블록에서 애플리케이션을 실행하도록 할 수 있습니다(애플리케이션 크기에 적합한 블록 선택). 이러한 분리를 통해 복제 및 재조정을 위한 MinIO 트래픽이 애플리케이션 성능에 영향을 미치지 않으며 그 반대의 경우도 마찬가지입니다. 또한 MinIO가 성능에 영향을 주지 않고 작업을 수행하는 데 필요한 용량과 대역폭을 항상 확보할 수 있도록 트래픽을 모니터링하고 추적하는 기능도 제공합니다.

하지만 여러 사이트나 지역에 MinIO가 있으면 어떻게 될까요? 성능 병목 현상이 발생하지 않도록 효과적으로 구성하려면 어떻게 해야 합니까? 글쎄, MinIO가 가장 엄격한 사용 사례에 대해 제공하는 여러 가지 유형의 복제 구성이 있습니다.

가장 많이 사용되는 복제 전략 중 하나는 사이트 간 복제입니다. 이를 통해 단일 클러스터로 MinIO를 시작하고 필요가 증가함에 따라 N개로 확장할 수 있습니다. 3개의 다른 사이트에서 실행되는 ETL/ELT 애플리케이션이 있다고 가정합니다. 일반적으로 데이터는 한 지역에서만 사용할 수 있으며 다른 지역에서는 프로세스를 실행하기 위해 여러 지역에서 막대한 양의 데이터를 가져와야 합니다. 말할 필요도 없이 이는 매우 비효율적일 뿐만 아니라 네트워킹 인프라에 엄청난 부담을 주며 잠재적으로 WAN을 공유하는 다른 애플리케이션에 병목 현상을 일으킬 수 있습니다.

사이트 간 복제 구성에서는 첫 번째 사이트의 MinIO 클러스터에만 데이터를 씁니다. 복제 프로세스는 데이터를 다른 사이트에 자동으로 복사합니다. ETL/ELT 애플리케이션에 추가로 변경해야 할 사항은 없습니다. 각 사이트의 작업을 Nginx와 같은 역방향 프록시가 지원하는 해당 MinIO 클러스터로 지정하기만 하면 아래와 같이 지역 전체에서 WAN을 통해 수행되는 것보다 읽기 속도가 훨씬 빨라집니다.

하지만 트래픽을 더욱 미세하게 조정할 수 있는지 의문이 듭니다. 사이트 1에 데이터 파일을 추가하면 하루 중 시간에 관계없이 즉시 다른 사이트에 복제됩니다. 다른 ETL/ELT 작업이 실행되고 동시에 네트워크 리소스가 다음 배치가 실행될 다음 날까지 사용되지 않을 수 있는 데이터를 복제하는 데 사용되는 피크 기간일 수 있습니다. 이 경우 어떻게 할 수 있나요? 이것이 MinIO의 일괄 복제 가 유용한 곳입니다. 일괄 복제를 사용하면 특정 시간에 복제하려는 데이터 유형을 선택하고 완전히 구성할 수 있습니다. 이 경우 트래픽이 가장 적은 업무 외 시간에 일괄 복제 작업이 실행되도록 설정할 수 있습니다. 애플리케이션 액세스 시간은 하루, 주, 심지어 월별로 달라질 수 있으므로 MinIO 네트워크 트래픽을 모니터링하는 것이 유용하므로 배치 작업이 정확한 시간에 실행되도록 구성할 수 있습니다. 다양한 랙, 데이터 센터 또는 지리적 영역에 피어 사이트를 배포하여 전 세계적으로 분산된 MinIO 개체 저장소에서 BC/DR 또는 지리적 로컬 읽기/쓰기 성능과 같은 기능을 지원할 수 있습니다.

마지막 생각들

요약하면 MinIO의 네트워크 아키텍처는 가장 간단하고 간단한 아키텍처 중 하나입니다. 바퀴를 재발명하는 대신 MinIO는 디버깅이 거의 불가능한 복잡한 네트워크 및 게이트웨이 설정을 통해 다른 데이터 저장소와 패리티를 달성하기 위해 네트워킹 기본을 사용합니다. 동일한 문제를 몇 번이나 디버깅하더라도 아키텍처의 난독화된 특성으로 인해 해당 문제가 처음으로 실행되는 것처럼 느껴질 것입니다. 오히려 MinIO는 애플리케이션 개발자가 데이터 복제를 유지해야 하는 부담을 덜어주고 데이터 저장 및 처리에 집중하는 더 높은 수준의 추상화에 중점을 둡니다.

평소와 마찬가지로 MinIO 네트워크 구성이나 설정 방법에 대해 질문이 있는 경우 Slack을 통해 문의하거나 SUBNET 구독에 등록하는 것이 좋습니다!