Yandex.Cloud에서 Virtual Private Cloud가 작동하는 방식과 사용자가 유용한 기능을 구현하는 데 도움을 주는 방식

안녕하세요. 제 이름은 Kostya Kramlich입니다. 저는 Yandex.Cloud의 Virtual Private Cloud 사업부의 주요 개발자입니다. 저는 가상 네트워크를 작업하고 있습니다. 짐작하실 수 있듯이 이 기사에서는 일반적인 Virtual Private Cloud(VPC) 장치와 특히 가상 네트워크에 대해 설명하겠습니다. 그리고 우리 서비스 개발자들이 사용자들의 피드백을 소중히 여기는 이유도 알게 될 것입니다. 하지만 가장 먼저 해야 할 일이 있습니다.

VPC란 무엇입니까?

요즘에는 서비스 배포를 위한 다양한 옵션이 있습니다. 그런 이야기가 점점 줄어들기를 바라지만, 누군가 여전히 관리자 책상 아래에 서버를 두고 있을 것이라고 확신합니다.

이제 서비스는 퍼블릭 클라우드로 이동하려고 시도하고 있으며 여기에서 VPC를 만나게 됩니다. VPC는 클라우드 안팎에서 사용자, 인프라, 플랫폼 및 기타 역량을 함께 연결하는 퍼블릭 클라우드의 일부입니다. 동시에 VPC를 사용하면 이러한 용량이 불필요하게 인터넷에 노출되는 것을 방지할 수 있으며 격리된 네트워크 내에 유지됩니다.

가상 네트워크가 외부에서 보이는 모습

VPC란 무엇보다도 VPNaaS, NATaas, LBaas 등과 같은 오버레이 네트워크 및 네트워크 서비스를 의미합니다. 그리고 이 모든 것은 이미 논의된 내결함성 네트워크 인프라 위에서 작동합니다. 훌륭한 기사 여기 하브레에서요.

가상 네트워크와 그 구조를 자세히 살펴보겠습니다.

두 가지 가용성 영역을 살펴보겠습니다. 우리는 VPC라고 부르는 가상 네트워크를 제공합니다. 실제로 이는 "회색" 주소의 고유성 공간을 정의합니다. 각 가상 네트워크 내에서 컴퓨팅 리소스에 할당할 수 있는 주소 공간을 완전히 제어할 수 있습니다.

네트워크는 글로벌합니다. 동시에 서브넷이라는 개체의 형태로 각 가용 영역에 투영됩니다. 각 서브넷에 대해 크기 16 이하의 CIDR을 할당합니다. 각 가용성 영역에는 이러한 엔터티가 두 개 이상 있을 수 있으며 이들 간에는 항상 투명한 라우팅이 있습니다. 이는 동일한 VPC 내의 모든 리소스가 서로 다른 가용 영역에 있더라도 서로 "대화"할 수 있음을 의미합니다. 인터넷에 접속하지 않고도 내부 채널을 통해 동일한 사설 네트워크 내에 있다고 "생각"하여 "통신"합니다.

위의 다이어그램은 주소 어딘가에서 교차하는 두 개의 VPC라는 일반적인 상황을 보여줍니다. 둘 다 당신의 것이 될 수 있습니다. 예를 들어 하나는 개발용이고 다른 하나는 테스트용입니다. 단순히 다른 사용자가 있을 수도 있습니다. 이 경우에는 중요하지 않습니다. 그리고 각 VPC에는 하나의 가상 머신이 있습니다.

계획을 더 악화시키자. 하나의 가상 머신을 여러 서브넷에 동시에 연결할 수 있습니다. 그리고 그뿐만 아니라 다른 가상 네트워크에도 있습니다.

동시에 인터넷에 머신을 노출해야 하는 경우 API나 UI를 통해 이를 수행할 수 있습니다. 이렇게 하려면 "회색" 내부 주소를 "흰색" 공용 주소로 NAT 변환하도록 구성해야 합니다. "화이트" 주소는 선택할 수 없으며 주소 풀에서 무작위로 할당됩니다. 외부 IP 사용을 중지하면 즉시 풀로 돌아갑니다. "화이트" 주소를 사용한 시간에 대해서만 비용을 지불하면 됩니다.

NAT 인스턴스를 사용하여 머신에 인터넷 액세스를 제공하는 것도 가능합니다. 정적 라우팅 테이블을 통해 인스턴스로 트래픽을 라우팅할 수 있습니다. 사용자들이 가끔 필요로 하는 경우가 있어서 이런 경우를 제공했고, 저희도 그 사실을 알고 있습니다. 따라서 이미지 디렉터리에는 특별히 구성된 NAT 이미지가 있습니다.

하지만 이미 만들어진 NAT 이미지가 있더라도 구성이 복잡할 수 있습니다. 일부 사용자에게는 이것이 가장 편리한 옵션이 아니라는 것을 이해했기 때문에 결국 한 번의 클릭으로 원하는 서브넷에 대해 NAT를 활성화할 수 있게 되었습니다. 이 기능은 아직 비공개 미리보기 액세스 상태이며 커뮤니티 구성원의 도움을 받아 테스트되고 있습니다.

가상 네트워크가 내부에서 작동하는 방식

사용자는 가상 네트워크와 어떻게 상호 작용합니까? 네트워크는 API를 통해 외부를 바라봅니다. 사용자가 API에 와서 대상 상태로 작업합니다. API를 통해 사용자는 모든 것이 어떻게 배열되고 구성되어야 하는지 확인하는 동시에 상태를 확인하고 실제 상태가 원하는 상태와 어떻게 다른지 확인합니다. 사용자의 사진입니다. 안에서 무슨 일이 일어나고 있는 걸까요?

Yandex 데이터베이스에 원하는 상태를 기록하고 VPC의 다른 부분을 구성합니다. Yandex.Cloud의 오버레이 네트워크는 최근 Tungsten Fabric이라고 불리는 OpenContrail의 선택된 구성 요소를 기반으로 구축되었습니다. 네트워크 서비스는 단일 CloudGate 플랫폼에서 구현됩니다. CloudGate에서는 제어 정보를 처리하기 위한 GoBGP와 데이터 경로용 DPDK 위에서 실행되는 소프트웨어 라우터를 구현하기 위한 VPP 등 다양한 오픈 소스 구성 요소도 사용했습니다.

Tungsten Fabric은 GoBGP를 통해 CloudGate와 통신합니다. 오버레이 네트워크에서 무슨 일이 일어나고 있는지 알려줍니다. CloudGate는 오버레이 네트워크를 서로 연결하고 인터넷에 연결합니다.

이제 가상 네트워크가 확장성 및 가용성 문제를 어떻게 해결하는지 살펴보겠습니다. 간단한 경우를 생각해 봅시다. 가용 영역이 하나 있고 그 안에 VPC가 두 개 생성되었습니다. 우리는 하나의 Tungsten Fabric 인스턴스를 배포했으며 여기에는 수만 개의 네트워크가 포함되어 있습니다. 네트워크는 CloudGate와 통신합니다. 이미 말했듯이 CloudGate는 서로 및 인터넷과의 연결을 보장합니다.

두 번째 가용 영역이 추가되었다고 가정해 보겠습니다. 첫 번째와는 완전히 독립적으로 실패해야 합니다. 따라서 두 번째 가용 영역에는 별도의 Tungsten Fabric 인스턴스를 설치해야 합니다. 이는 오버레이를 처리하고 첫 번째 시스템에 대해 거의 알지 못하는 별도의 시스템입니다. 그리고 우리의 가상 네트워크가 글로벌한 것처럼 보이는 것은 실제로 우리의 VPC API를 생성합니다. 이것이 그의 임무입니다.

가용 영역 B에 VPC1에 고정된 리소스가 있는 경우 VPC1은 가용 영역 B에 매핑됩니다. 가용성 영역 B에 VPC2의 리소스가 없으면 이 영역에서 VPC2를 구체화하지 않습니다. 결과적으로 VPC3의 리소스는 영역 B에만 존재하므로 영역 A에는 VPC3가 존재하지 않습니다. 모든 것이 간단하고 논리적입니다.

조금 더 깊이 들어가 Y.Cloud의 특정 호스트가 어떻게 작동하는지 살펴보겠습니다. 제가 주목하고 싶은 가장 중요한 점은 모든 호스트가 동일하게 설계되었다는 것입니다. 우리는 필요한 최소한의 서비스만 하드웨어에서 실행되고 나머지는 모두 가상 머신에서 실행되도록 합니다. 우리는 기본 인프라 서비스를 기반으로 고차원적인 서비스를 구축하고 클라우드를 사용하여 지속적인 통합 등의 일부 엔지니어링 문제를 해결합니다.

특정 호스트를 살펴보면 호스트 OS에서 실행되는 세 가지 구성 요소가 있음을 알 수 있습니다.

• 컴퓨팅은 호스트에 컴퓨팅 리소스를 분산시키는 역할을 담당하는 부분입니다.
• VRouter는 오버레이를 구성하는 텅스텐 패브릭의 일부입니다. 즉, 언더레이를 통해 패킷을 터널링합니다.
• VDisk는 스토리지 가상화의 일부입니다.

또한 가상 머신은 클라우드 인프라 서비스, 플랫폼 서비스 및 고객 용량과 같은 서비스를 실행합니다. 고객의 역량과 플랫폼 서비스는 항상 VRouter를 통해 오버레이로 이동합니다.

인프라 서비스는 오버레이에 연결할 수 있지만 대부분은 언더레이에서 작업하기를 원합니다. SR-IOV를 사용하여 언더레이에 고정됩니다. 실제로 성능 저하를 방지하기 위해 카드를 가상 네트워크 카드(가상 기능)로 잘라 인프라 가상 머신에 밀어넣습니다. 예를 들어, 동일한 CloudGate가 이러한 인프라 가상 머신 중 하나로 시작됩니다.

이제 가상 네트워크의 전역 작업과 클라우드 기본 구성 요소의 설계를 설명했으므로 가상 네트워크의 서로 다른 부분이 정확히 어떻게 서로 상호 작용하는지 살펴보겠습니다.

우리 시스템에서는 세 가지 계층을 구분합니다.

• 구성 평면 – 시스템의 대상 상태를 설정합니다. 이는 사용자가 API를 통해 구성하는 것입니다.
• 제어 플레인 – 사용자 지정 의미 체계를 제공합니다. 즉, 사용자가 구성 플레인에서 설명한 데이터 플레인의 상태를 가져옵니다.
• 데이터 플레인 – 사용자 패킷을 직접 처리합니다.

위에서 말했듯이 모든 것은 사용자 또는 내부 플랫폼 서비스가 API에 와서 특정 대상 상태를 설명하는 것으로 시작됩니다.

이 상태는 Yandex 데이터베이스에 즉시 기록되고 API를 통해 비동기 작업의 ID를 반환하며 내부 기계를 시작하여 사용자가 원하는 상태를 생성합니다. 구성 작업은 SDN 컨트롤러로 이동하여 Tungsten Fabric에 오버레이에서 수행해야 할 작업을 알려줍니다. 예를 들어 포트, 가상 네트워크 등을 예약합니다.

Tungsten Fabric의 구성 평면은 필요한 상태를 제어 평면에 업로드합니다. 이를 통해 구성 평면은 호스트와 통신하여 가까운 미래에 호스트에서 정확히 무엇이 실행될 것인지 알려줍니다.

이제 호스트에서 시스템이 어떻게 보이는지 살펴보겠습니다. 가상 머신에는 VRouter에 연결된 특정 네트워크 어댑터가 있습니다. VRouter는 패킷을 보는 Tungsten Fabric 코어 모듈입니다. 일부 패킷에 대한 흐름이 이미 있는 경우 모듈은 이를 처리합니다. 흐름이 없으면 모듈은 소위 펀팅(Punting)을 수행합니다. 즉, 패킷을 usermod 프로세스로 보냅니다. 프로세스는 패킷을 구문 분석하고 DHCP 및 DNS와 같이 패킷 자체에 응답하거나 VRouter에게 패킷 처리 방법을 알려줍니다. 그런 다음 VRouter는 패킷을 처리할 수 있습니다.

또한 동일한 가상 네트워크 내의 가상 머신 간의 트래픽은 투명하게 흐르며 CloudGate로 전송되지 않습니다. 가상 머신이 배포된 호스트는 서로 직접 통신합니다. 트래픽을 터널링하고 언더레이를 통해 서로 전달합니다.

컨트롤 플레인은 다른 라우터와 마찬가지로 BGP를 통해 가용 영역에서 서로 통신합니다. 어떤 머신이 어디에 설치되어 있는지 알려주므로 한 영역의 가상 머신이 다른 가상 머신과 직접 통신할 수 있습니다.

Control Plane은 CloudGate와도 통신합니다. 마찬가지로 가상 머신이 설치된 위치와 주소, 주소가 무엇인지 보고합니다. 이를 통해 외부 트래픽과 밸런서의 트래픽을 밸런서로 전달할 수 있습니다.

VPC를 떠나는 트래픽은 데이터 경로의 CloudGate로 전달되며, 여기서 플러그인이 포함된 VPP가 빠르게 씹어집니다. 그런 다음 트래픽은 CloudGate 자체의 제어 평면을 통해 구성된 다른 VPC로 또는 외부의 에지 라우터로 전송됩니다.

가까운 미래를위한 계획

위에서 언급한 모든 내용을 몇 문장으로 요약하면 Yandex.Cloud의 VPC는 ​​두 가지 중요한 문제를 해결한다고 말할 수 있습니다.

• 서로 다른 클라이언트 간의 격리를 제공합니다.
• 리소스, 인프라, 플랫폼 서비스, 기타 클라우드 및 온프레미스를 단일 네트워크로 통합합니다.

그리고 이러한 문제를 잘 해결하려면 내부 아키텍처 수준에서 확장성과 내결함성을 확보해야 하는데 이것이 바로 VPC가 하는 일입니다.

점차적으로 VPC는 ​​기능을 확보하고 있으며, 새로운 기능을 구현하고 있으며, 사용자 편의성 측면에서 개선을 위해 노력하고 있습니다. 커뮤니티 구성원 덕분에 일부 아이디어가 표명되고 우선순위 목록에 포함되었습니다.

이제 우리는 가까운 미래에 대해 대략 다음과 같은 계획 목록을 가지고 있습니다.

• 서비스로서의 VPN.
• 프라이빗 DNS 인스턴스 – 사전 구성된 DNS 서버로 가상 머신을 빠르게 설정하기 위한 이미지입니다.
• 서비스로서의 DNS.
• 내부 부하 분산기.
• 가상 머신을 다시 생성하지 않고 "화이트" IP 주소를 추가합니다.

사용자의 요청에 따라 이미 생성된 가상 머신의 IP 주소를 전환하는 기능과 밸런서가 이 목록에 포함되었습니다. 솔직히 말해서 명시적인 피드백이 없었다면 우리는 이러한 기능을 조금 나중에 수행했을 것입니다. 그래서 우리는 이미 주소에 관한 문제를 해결하고 있습니다.

처음에는 "화이트" IP 주소는 머신을 생성할 때만 추가할 수 있었습니다. 사용자가 이 작업을 잊어버린 경우 가상 머신을 다시 만들어야 했습니다. 필요한 경우 외부 IP를 제거하는 경우에도 마찬가지입니다. 머지않아 머신을 다시 생성하지 않고도 공용 IP를 켜고 끌 수 있게 될 것입니다.

마음껏 표현해보세요 아이디어 및 지원 제안 다른 사용자. 여러분은 우리가 클라우드를 더 좋게 만들고 중요하고 유용한 기능을 더 빨리 얻을 수 있도록 도와줍니다!

출처 : habr.com