클라우드 인프라의 네트워크 부분 소개

클라우드 컴퓨팅은 우리 삶 속으로 점점 더 깊숙이 침투하고 있으며, 클라우드 서비스를 한 번이라도 사용해보지 않은 사람은 없을 것입니다. 그러나 클라우드가 정확히 무엇인지, 어떻게 작동하는지 아는 사람은 거의 없으며 아이디어 수준에서도 마찬가지입니다. 5G는 이미 현실이 되고 있으며 통신 인프라는 완전한 하드웨어 솔루션에서 가상화된 "기둥"으로 전환했을 때와 마찬가지로 기둥 솔루션에서 클라우드 솔루션으로 이동하기 시작했습니다.

오늘은 클라우드 인프라의 내부 세계에 대해 이야기하고, 특히 네트워크 부분의 기본 사항을 살펴보겠습니다.

클라우드란 무엇입니까? 동일한 가상화 - 프로필 보기?

논리적인 질문 그 이상입니다. 아니요. 가상화 없이는 불가능하지만 가상화는 아닙니다. 두 가지 정의를 살펴보겠습니다.

클라우드 컴퓨팅(이하 클라우드) 분산 컴퓨팅 리소스에 대한 사용자 친화적인 액세스를 제공하기 위한 모델입니다. 분산 컴퓨팅 리소스는 서비스 제공업체에 대한 대기 시간을 최소화하고 비용을 최소화하면서 온디맨드 방식으로 배포 및 실행되어야 합니다.

가상화 - 이는 하나의 물리적 엔터티(예: 서버)를 여러 개의 가상 엔터티로 나누어 리소스 활용도를 높이는 기능입니다. 예를 들어 3개의 서버가 25-30%로 로드되었으나 가상화 후에는 1개의 서버가 로드됩니다. 80-90%). 당연히 가상화는 일부 리소스를 소모합니다. 하이퍼바이저에 공급해야 하지만 실습에서 알 수 있듯이 게임은 그만한 가치가 있습니다. 가상화의 이상적인 예는 가상 머신을 완벽하게 준비하는 VMWare 또는 예를 들어 제가 선호하는 KVM이지만 이는 취향의 문제입니다.

우리는 이를 깨닫지 못한 채 가상화를 사용하고 있으며 심지어 철 라우터도 이미 가상화를 사용하고 있습니다. 예를 들어 최신 버전의 JunOS에서는 운영 체제가 실시간 Linux 배포판(Wind River 9) 위에 가상 머신으로 설치됩니다. 하지만 가상화는 클라우드가 아니지만 가상화 없이는 클라우드가 존재할 수 없습니다.

가상화는 클라우드가 구축되는 구성 요소 중 하나입니다.

단순히 여러 개의 하이퍼바이저를 하나의 L2 도메인에 모아서 클라우드를 만들고, 일종의 앤서블을 통해 자동으로 VLAN을 등록하기 위한 두 개의 yaml 플레이북을 추가하고, 자동으로 가상 머신을 생성하기 위해 오케스트레이션 시스템과 같은 것을 여기에 재밍하는 것은 작동하지 않습니다. 더 정확하겠지만, 결과적으로 생성된 프랑켄슈타인은 비록 다른 사람들에게는 궁극적인 꿈일 수 있지만 우리에게 필요한 클라우드는 아닙니다. 게다가 동일한 Openstack을 사용하면 본질적으로 여전히 프랑켄슈타인이지만 아 뭐, 지금은 그것에 대해 이야기하지 않겠습니다.

그러나 위에 제시된 정의에서 실제로 클라우드라고 할 수 있는 것이 무엇인지 완전히 명확하지 않다는 것을 이해합니다.

따라서 NIST(National Institute of Standards and Technology)의 문서에서는 클라우드 인프라가 갖춰야 할 5가지 주요 특징을 제시합니다.

요청 시 서비스를 제공합니다. 사용자는 자신에게 할당된 컴퓨터 리소스(예: 네트워크, 가상 디스크, 메모리, 프로세서 코어 등)에 무료로 액세스할 수 있어야 하며 이러한 리소스는 자동으로, 즉 서비스 제공업체의 개입 없이 제공되어야 합니다.

광범위한 서비스 가용성. 표준 PC와 씬 클라이언트, 모바일 장치를 모두 사용할 수 있도록 표준 메커니즘을 통해 리소스에 대한 액세스를 제공해야 합니다.

리소스를 풀로 결합합니다. 리소스 풀은 동시에 여러 클라이언트에게 리소스를 제공할 수 있어야 하며 클라이언트가 격리되고 상호 영향과 리소스 경쟁이 없도록 보장해야 합니다. 네트워크도 풀에 포함되어 있으며 이는 중복 주소 지정을 사용할 가능성을 나타냅니다. 풀은 필요에 따라 확장할 수 있어야 합니다. 풀을 사용하면 필요한 수준의 리소스 내결함성과 물리적 및 가상 리소스의 추상화를 제공할 수 있습니다. 서비스 수신자에게는 요청한 리소스 세트(이러한 리소스가 물리적으로 위치한 위치, 리소스의 수)가 간단히 제공됩니다. 서버 및 스위치 - 클라이언트에는 중요하지 않습니다. 그러나 공급자가 이러한 자원을 투명하게 확보해야 한다는 사실을 고려해야 합니다.

다양한 조건에 대한 빠른 적응. 서비스는 유연해야 합니다. 리소스를 신속하게 제공하고, 재분배하고, 클라이언트의 요청에 따라 리소스를 추가 또는 축소해야 하며, 클라이언트 측에서는 클라우드 리소스가 끝이 없다는 느낌이 있어야 합니다. 예를 들어, 이해를 돕기 위해 서버의 하드 드라이브가 고장나서 드라이브가 고장나서 Apple iCloud의 디스크 공간 일부가 사라졌다는 경고가 표시되지 않습니다. 또한 귀하의 입장에서 이 서비스의 가능성은 거의 무한합니다. 2TB가 필요합니다. 문제 없습니다. 비용을 지불하고 받았습니다. Google.Drive 또는 Yandex.Disk에서도 비슷한 예를 들 수 있습니다.

제공된 서비스를 측정할 가능성. 클라우드 시스템은 소비되는 리소스를 자동으로 제어하고 최적화해야 하며 이러한 메커니즘은 사용자와 서비스 제공자 모두에게 투명해야 합니다. 즉, 귀하와 귀하의 고객이 얼마나 많은 리소스를 소비하고 있는지 항상 확인할 수 있습니다.

이러한 요구 사항은 대부분 퍼블릭 클라우드에 대한 요구 사항이라는 점을 고려해 볼 가치가 있으므로 프라이빗 클라우드(즉, 회사 내부 요구에 따라 출시된 클라우드)의 경우 이러한 요구 사항을 약간 조정할 수 있습니다. 그러나 여전히 완료해야 하는 작업입니다. 그렇지 않으면 클라우드 컴퓨팅의 모든 이점을 얻을 수 없습니다.

클라우드가 왜 필요한가요?

그러나 새로운 기술이나 기존 기술, 새로운 프로토콜은 무언가를 위해 생성됩니다(물론 RIP-ng는 제외). 프로토콜을 위해 프로토콜이 필요한 사람은 없습니다(물론 RIP-ng를 제외하고). 사용자/클라이언트에게 일종의 서비스를 제공하기 위해 클라우드가 생성된다는 것은 논리적입니다. 우리 모두는 Dropbox 또는 Google.Docs와 같은 최소한 두 가지 클라우드 서비스에 대해 잘 알고 있으며 대부분의 사람들이 이를 성공적으로 사용한다고 생각합니다. 예를 들어 이 기사는 Google.Docs 클라우드 서비스를 사용하여 작성되었습니다. 하지만 우리가 알고 있는 클라우드 서비스는 클라우드 기능의 일부일 뿐, 더 정확하게는 SaaS 형태의 서비스일 뿐입니다. 우리는 SaaS, PaaS, IaaS의 세 가지 형태로 클라우드 서비스를 제공할 수 있습니다. 필요한 서비스는 귀하의 욕구와 능력에 따라 다릅니다.

각각을 순서대로 살펴보겠습니다.

SaaS (Software as a Service) Yandex.Mail 또는 Gmail과 같은 이메일 서비스와 같이 클라이언트에 본격적인 서비스를 제공하기 위한 모델입니다. 이 서비스 제공 모델에서는 클라이언트로서 귀하는 실제로 서비스를 사용하는 것 외에는 아무것도 하지 않습니다. 즉, 서비스 설정, 내결함성 또는 중복성에 대해 생각할 필요가 없습니다. 가장 중요한 것은 귀하의 비밀번호를 훼손하지 않는 것입니다. 이 서비스 제공업체가 귀하를 위해 나머지 작업을 수행할 것입니다. 서비스 제공자의 관점에서 그는 서버 하드웨어 및 호스트 운영 체제부터 데이터베이스 및 소프트웨어 설정에 이르기까지 전체 서비스를 전적으로 책임집니다.

서비스 형 플랫폼 (PaaS) — 이 모델을 사용할 때 서비스 공급자는 클라이언트에게 서비스를 위한 작업물을 제공합니다(예: 웹 서버). 서비스 제공자는 클라이언트에게 가상 서버(사실상 RAM/CPU/스토리지/Net 등의 리소스 집합)를 제공하고 이 서버에 OS와 필요한 소프트웨어까지 설치했지만, 이 모든 작업은 클라이언트가 직접 수행하며 클라이언트가 응답하는 서비스 성능을 위해 수행됩니다. 이전 사례와 마찬가지로 서비스 제공자는 물리적 장비, 하이퍼바이저, 가상 머신 자체, 네트워크 가용성 등의 성능을 책임지지만 서비스 자체는 더 이상 책임 영역에 속하지 않습니다.

인프라로서의 서비스 (IaaS) - 이 접근 방식은 이미 더 흥미롭습니다. 실제로 서비스 공급자는 클라이언트에게 완전한 가상화 인프라, 즉 CPU 코어, RAM, 네트워크 등과 같은 일부 리소스 세트(풀)를 제공합니다. 클라이언트 - 클라이언트가 할당된 풀(할당량) 내에서 이러한 리소스를 사용하여 수행하려는 작업은 공급자에게 특별히 중요하지 않습니다. 고객이 자신만의 vEPC를 만들고 싶든, 미니 운영자를 만들고 통신 서비스를 제공하고 싶든 상관없이 그렇게 하세요. 이러한 시나리오에서 서비스 공급자는 리소스, 내결함성 및 가용성을 프로비저닝하고 이러한 리소스를 풀링하고 언제든지 리소스를 늘리거나 줄일 수 있는 기능을 통해 클라이언트가 사용할 수 있도록 하는 OS를 담당합니다. 클라이언트의 요청에 따라. 클라이언트는 네트워크 설정(외부 네트워크 제외)을 포함하여 셀프 서비스 포털 및 콘솔을 통해 모든 가상 머신 및 기타 반짝이를 직접 구성합니다.

오픈스택이란 무엇입니까?

세 가지 옵션 모두에서 서비스 제공업체에는 클라우드 인프라 생성을 지원하는 OS가 필요합니다. 실제로 SaaS의 경우 하나 이상의 부서가 전체 기술 스택을 담당합니다. 인프라를 담당하는 부서가 있습니다. 즉, 다른 부서에 IaaS를 제공하고 이 부서는 고객에게 SaaS를 제공합니다. OpenStack은 여러 스위치, 서버 및 스토리지 시스템을 단일 리소스 풀로 수집하고, 이 공통 풀을 하위 풀(테넌트)로 분할하고, 이러한 리소스를 네트워크를 통해 클라이언트에 제공할 수 있는 클라우드 운영 체제 중 하나입니다.

OpenStack 표준 인증 메커니즘을 사용하여 API를 통해 프로비저닝 및 관리되는 대규모 컴퓨팅 리소스 풀, 데이터 스토리지 및 네트워크 리소스를 제어할 수 있는 클라우드 운영 체제입니다.

즉, 이는 클라우드 서비스(퍼블릭 및 프라이빗 모두)를 생성하도록 설계된 무료 소프트웨어 프로젝트 세트입니다. 즉, 서버와 스위칭 장비를 단일 리소스 풀로 결합하고 관리할 수 있는 도구 세트입니다. 이러한 리소스는 필요한 수준의 내결함성을 제공합니다.

이 자료를 작성할 당시 OpenStack 구조는 다음과 같습니다.

사진 출처: openstack.org

OpenStack에 포함된 각 구성 요소는 특정 기능을 수행합니다. 이 분산 아키텍처를 사용하면 필요한 기능 구성 요소 집합을 솔루션에 포함할 수 있습니다. 그러나 일부 구성 요소는 루트 구성 요소이므로 이를 제거하면 솔루션 전체가 완전히 또는 부분적으로 작동하지 않게 됩니다. 이러한 구성 요소는 일반적으로 다음과 같이 분류됩니다.

• 대시보드 — OpenStack 서비스 관리를 위한 웹 기반 GUI
• 요지 다른 서비스에 대한 인증 및 권한 부여 기능을 제공하고 사용자 자격 증명 및 해당 역할을 관리하는 중앙 집중식 ID 서비스입니다.
• 중성자 - 다양한 OpenStack 서비스의 인터페이스 간 연결을 제공하는 네트워크 서비스(VM 간의 연결 및 외부 세계에 대한 액세스 포함)
• 신더 — 가상 머신용 블록 스토리지에 대한 액세스를 제공합니다.
• 신성 — 가상 머신의 수명 주기 관리
• 섬광 — 가상 머신 이미지 및 스냅샷 저장소
• 빠른 — 저장소 개체에 대한 액세스를 제공합니다.
• 운고계 — 원격 측정을 수집하고 사용 가능하고 소비되는 리소스를 측정하는 기능을 제공하는 서비스
• 열 — 리소스 자동 생성 및 프로비저닝을 위한 템플릿 기반 조정

모든 프로젝트와 그 목적의 전체 목록을 볼 수 있습니다. 여기에.

각 OpenStack 구성 요소는 특정 기능을 수행하고 해당 기능을 관리하고 다른 클라우드 운영 체제 서비스와 상호 작용하여 통합 인프라를 생성하는 API를 제공하는 서비스입니다. 예를 들어, Nova는 컴퓨팅 리소스 관리와 이러한 리소스 구성에 액세스하기 위한 API를 제공하고, Glance는 이미지 관리와 이를 관리하기 위한 API를 제공하고, Cinder는 블록 스토리지와 이를 관리하기 위한 API를 제공합니다. 모든 기능은 매우 긴밀하게 상호 연결되어 있습니다.

하지만 따지고 보면 OpenStack에서 실행되는 모든 서비스는 결국 네트워크에 연결된 일종의 가상 머신(혹은 컨테이너)입니다. 질문이 생깁니다. 왜 그렇게 많은 요소가 필요한가요?

OpenStack에서 가상 머신을 생성하고 이를 네트워크 및 영구 스토리지에 연결하는 알고리즘을 살펴보겠습니다.

1. Horizon(대시보드)을 통한 요청이든 CLI를 통한 요청이든 머신 생성 요청을 생성할 때 가장 먼저 발생하는 일은 Keystone에 대한 요청 승인입니다. 머신을 생성할 수 있습니까? 이 네트워크를 사용할 수 있는 권리, 초안 할당량 등을 확인하세요.
2. Keystone은 요청을 인증하고 응답 메시지에 인증 토큰을 생성합니다. 이 토큰은 나중에 사용됩니다. Keystone으로부터 응답을 받은 후 요청은 Nova(nova api)로 전송됩니다.
3. Nova-api는 이전에 생성된 인증 토큰을 사용하여 Keystone에 연락하여 요청의 유효성을 확인합니다.
4. Keystone은 인증을 수행하고 이 인증 토큰을 기반으로 권한 및 제한 사항에 대한 정보를 제공합니다.
5. Nova-api는 nova-database에 새 VM에 대한 항목을 생성하고 머신 생성 요청을 nova-scheduler에 전달합니다.
6. Nova-scheduler는 지정된 매개변수, 가중치 및 영역을 기반으로 VM이 배포될 호스트(컴퓨터 노드)를 선택합니다. 이에 대한 기록과 VM ID가 nova-database에 기록됩니다.
7. 다음으로, nova-scheduler는 nova-compute에 접속하여 인스턴스 배포를 요청합니다. Nova-compute는 nova-conductor에 접속하여 기계 매개변수에 대한 정보를 얻습니다(nova-conductor는 nova-database와 nova-compute 사이에서 프록시 서버 역할을 하는 nova 요소로, 데이터베이스 문제를 피하기 위해 nova-database에 대한 요청 수를 제한합니다) 일관성 부하 감소).
8. Nova-conductor는 nova-database에서 요청된 정보를 수신하여 nova-compute에 전달합니다.
9. 다음으로 nova-compute는 시선을 호출하여 이미지 ID를 얻습니다. Glace는 Keystone에서 요청을 검증하고 요청된 정보를 반환합니다.
10. Nova-compute는 중성자와 접촉하여 네트워크 매개변수에 대한 정보를 얻습니다. Glance와 유사하게 Neutron은 Keystone에서 요청의 유효성을 검사한 후 데이터베이스에 항목(포트 식별자 등)을 생성하고 포트 생성 요청을 생성한 후 요청된 정보를 nova-compute에 반환합니다.
11. Nova-compute은 가상 머신에 볼륨을 할당해 달라는 요청으로 cinder에 연락합니다. Glance와 마찬가지로 Cider는 Keystone에서 요청을 검증하고 볼륨 생성 요청을 생성한 후 요청된 정보를 반환합니다.
12. Nova-compute은 libvirt에 연락하여 지정된 매개변수를 사용하여 가상 머신을 배포해 달라는 요청을 보냅니다.

실제로 간단한 가상 머신을 생성하는 겉보기에는 간단한 작업이 클라우드 플랫폼 요소 간의 API 호출 소용돌이로 변합니다. 게다가 보시다시피 이전에 지정된 서비스도 상호 작용이 발생하는 더 작은 구성 요소로 구성됩니다. 머신을 생성하는 것은 클라우드 플랫폼에서 수행할 수 있는 작업 중 작은 부분일 뿐입니다. 트래픽 균형을 담당하는 서비스, 블록 스토리지를 담당하는 서비스, DNS를 담당하는 서비스, 베어메탈 서버 프로비저닝을 담당하는 서비스 등이 있습니다. 클라우드를 사용하면 가상 머신을 양떼처럼 다룰 수 있습니다(가상화가 아닌). 가상 환경에서 머신에 문제가 발생하면 백업 등을 통해 머신을 복원하지만 클라우드 애플리케이션은 가상 머신이 그렇게 중요한 역할을 하지 않는 방식으로 구축됩니다. 즉, 가상 머신이 "죽었습니다". 문제 없습니다. - 템플릿을 기반으로 새로운 차량이 생성되었으며, 그들이 말했듯이 분대는 전투기의 손실을 알아차리지 못했습니다. 당연히 이는 오케스트레이션 메커니즘을 제공합니다. Heat 템플릿을 사용하면 수십 개의 네트워크와 가상 머신으로 구성된 복잡한 기능을 쉽게 배포할 수 있습니다.

네트워크 없이는 클라우드 인프라가 없다는 점을 항상 명심할 가치가 있습니다. 각 요소는 어떤 방식으로든 네트워크를 통해 다른 요소와 상호 작용합니다. 또한 클라우드에는 완전히 비정적 네트워크가 있습니다. 당연히 언더레이 네트워크는 다소 정적입니다. 새로운 노드와 스위치는 매일 추가되지 않지만 오버레이 구성 요소는 지속적으로 변경될 수 있으며 필연적으로 변경됩니다. 새로운 네트워크가 추가되거나 삭제되고, 새로운 가상 머신이 나타나고 이전 네트워크는 나타날 것입니다. 주사위. 그리고 기사의 시작 부분에 제공된 클라우드 정의에서 기억했듯이 리소스는 서비스 제공업체의 개입을 최소한으로(또는 더 좋게는) 하지 않고 자동으로 사용자에게 할당되어야 합니다. 즉, 현재 http/https를 통해 액세스할 수 있는 개인 계정의 형태로 프런트엔드 형태로 존재하는 네트워크 리소스 제공 유형과 백엔드로 근무하는 네트워크 엔지니어인 Vasily는 클라우드가 아닙니다. 바실리의 손이 여덟 개인 경우.

네트워크 서비스인 Neutron은 클라우드 인프라의 네트워크 부분을 관리하기 위한 API를 제공합니다. 이 서비스는 NaaS(Network-as-a-Service)라는 추상화 계층을 제공하여 Openstack의 네트워킹 부분을 강화하고 관리합니다. 즉, 네트워크는 가상 CPU 코어나 RAM 용량과 같은 가상 측정 가능 단위입니다.

그러나 OpenStack의 네트워크 부분 아키텍처로 이동하기 전에 이 네트워크가 OpenStack에서 작동하는 방식과 네트워크가 클라우드의 중요하고 필수적인 부분인 이유를 고려해 보겠습니다.

따라서 두 개의 RED 클라이언트 VM과 두 개의 GREEN 클라이언트 VM이 있습니다. 이러한 머신이 다음과 같은 방식으로 두 개의 하이퍼바이저에 위치한다고 가정해 보겠습니다.

현재 이것은 단지 4개의 서버를 가상화한 것일 뿐이고 그 이상은 아닙니다. 지금까지 우리가 한 일은 4개의 서버를 가상화하여 두 개의 물리적 서버에 배치하는 것뿐이기 때문입니다. 그리고 지금까지는 네트워크에 연결되어 있지도 않습니다.

클라우드를 만들려면 여러 구성요소를 추가해야 합니다. 먼저 네트워크 부분을 가상화합니다. 이 4개의 머신을 쌍으로 연결해야 하며 클라이언트는 L2 연결을 원합니다. 스위치를 사용하고 해당 방향으로 트렁크를 구성하고 Linux 브리지를 사용하거나 고급 사용자의 경우 openvswitch(나중에 이에 대해 다시 설명)를 사용하여 모든 것을 해결할 수 있습니다. 그러나 네트워크가 많을 수 있으며 스위치를 통해 지속적으로 L2를 추진하는 것은 최선의 아이디어가 아닙니다. 다양한 부서, 서비스 데스크, 애플리케이션이 완료될 때까지 몇 달을 기다리고 문제 해결에 몇 주가 소요됩니다. 현대 세계에서는 이것이 접근 방식이 더 이상 작동하지 않습니다. 그리고 회사가 이를 빨리 이해할수록 앞으로 나아가는 것이 더 쉬워집니다. 따라서 하이퍼바이저 사이에서 가상 머신이 통신할 L3 네트워크를 선택하고, 이 L3 네트워크 위에 가상 머신의 트래픽이 실행될 가상 L2 오버레이 네트워크를 구축합니다. 캡슐화로 GRE, Geneve 또는 VxLAN을 사용할 수 있습니다. 특별히 중요하지는 않지만 지금은 후자에 초점을 맞춰 보겠습니다.

VTEP를 어딘가에 찾아야 합니다(모든 사람이 VxLAN 용어에 익숙하기를 바랍니다). 서버에서 바로 L3 네트워크가 연결되므로 서버 자체에 VTEP를 배치하는 것을 막을 수 있는 방법이 없으며 OVS(OpenvSwitch)는 이 작업을 훌륭하게 수행합니다. 그 결과 다음과 같은 디자인을 얻었습니다.

VM 간의 트래픽은 나누어져야 하므로 가상 머신으로 향하는 포트는 서로 다른 VLAN 번호를 갖게 됩니다. 태그 번호는 하나의 가상 스위치 내에서만 역할을 합니다. VxLAN에 캡슐화하면 VNI가 있으므로 쉽게 제거할 수 있기 때문입니다.

이제 문제 없이 머신과 가상 네트워크를 생성할 수 있습니다.

그러나 클라이언트에 다른 시스템이 있지만 다른 네트워크에 있는 경우에는 어떻게 될까요? 네트워크 간 루팅이 필요합니다. 중앙 집중식 라우팅을 사용할 때 간단한 옵션을 살펴보겠습니다. 즉, 트래픽은 특수 전용 네트워크 노드를 통해 라우팅됩니다(일반적으로 제어 노드와 결합되므로 동일한 내용을 갖게 됩니다).

복잡하지 않은 것 같습니다. 제어 노드에 브리지 인터페이스를 만들고 트래픽을 그곳으로 유도한 다음 필요한 곳으로 라우팅합니다. 그런데 문제는 RED 클라이언트는 10.0.0.0/24 네트워크를 사용하고, GREEN 클라이언트는 10.0.0.0/24 네트워크를 사용하려고 한다는 것입니다. 즉, 주소 공간을 교차하기 시작합니다. 또한 클라이언트는 다른 클라이언트가 내부 네트워크로 라우팅되는 것을 원하지 않습니다. 이는 타당합니다. 네트워크와 클라이언트 데이터 트래픽을 분리하기 위해 각각에 대해 별도의 네임스페이스를 할당합니다. 네임스페이스는 실제로 Linux 네트워크 스택의 복사본입니다. 즉, 네임스페이스 RED의 클라이언트는 네임스페이스 GREEN의 클라이언트와 완전히 격리됩니다(음, 이러한 클라이언트 네트워크 간의 라우팅은 기본 네임스페이스 또는 업스트림 전송 장비를 통해 허용됩니다).

즉, 다음 다이어그램을 얻습니다.

L2 터널은 모든 컴퓨팅 노드에서 제어 노드로 수렴됩니다. 이러한 네트워크의 L3 인터페이스가 있는 노드는 각각 격리를 위한 전용 네임스페이스에 있습니다.

그러나 우리는 가장 중요한 것을 잊었습니다. 가상 머신은 클라이언트에 서비스를 제공해야 합니다. 즉, 접속할 수 있는 외부 인터페이스가 하나 이상 있어야 합니다. 즉, 우리는 바깥세계로 나가야 한다. 여기에는 다양한 옵션이 있습니다. 가장 간단한 옵션을 시도해 보겠습니다. 우리는 각 클라이언트에 하나의 네트워크를 추가할 것입니다. 이는 공급자의 네트워크에서 유효하며 다른 네트워크와 중복되지 않습니다. 네트워크는 공급자 네트워크 측면에서 서로 다른 VRF를 교차하고 볼 수도 있습니다. 네트워크 데이터는 각 클라이언트의 네임스페이스에도 존재합니다. 그러나 그들은 여전히 ​​하나의 물리적(또는 보다 논리적인 결합) 인터페이스를 통해 외부 세계로 나갈 것입니다. 클라이언트 트래픽을 분리하기 위해 외부로 나가는 트래픽에는 클라이언트에 할당된 VLAN 태그가 지정됩니다.

그 결과 다음과 같은 다이어그램을 얻었습니다.

합리적인 질문은 왜 컴퓨팅 노드 자체에 게이트웨이를 만들지 않는가 하는 것입니다. 이는 큰 문제는 아니며, 분산 라우터(DVR)를 켜면 작동됩니다. 이 시나리오에서는 OpenStack에서 기본적으로 사용되는 중앙 집중식 게이트웨이를 사용하는 가장 간단한 옵션을 고려하고 있습니다. 고부하 기능의 경우 분산 라우터와 SR-IOV, 패스스루 등의 가속 기술을 모두 사용하지만, 말하는 바와 같이 이는 완전히 다른 이야기입니다. 먼저 기본적인 부분을 살펴본 후, 세부적인 내용을 살펴보겠습니다.

실제로 우리 계획은 이미 실행 가능하지만 몇 가지 미묘한 차이가 있습니다.

• 우리는 어떻게든 우리 머신을 보호해야 합니다. 즉, 클라이언트를 향한 스위치 인터페이스에 필터를 놓아야 합니다.
• 매번 콘솔을 통해 로그인하여 주소를 등록할 필요가 없도록 가상머신이 IP 주소를 자동으로 획득할 수 있도록 합니다.

기계를 보호하는 것부터 시작하겠습니다. 이를 위해 평범한 iptables를 사용할 수 있습니다. 왜 안 될까요?

즉, 이제 토폴로지가 좀 더 복잡해졌습니다.

계속 진행합시다. DHCP 서버를 추가해야 합니다. 각 클라이언트에 대한 DHCP 서버를 찾는 가장 이상적인 장소는 위에서 이미 언급한 네임스페이스가 있는 제어 노드입니다.

그러나 작은 문제가 있습니다. 모든 것이 재부팅되고 DHCP 주소 임대에 대한 모든 정보가 사라지면 어떻게 될까요? 기계에 새로운 주소가 부여되는 것은 논리적이지만 이는 그리 편리하지 않습니다. 여기에는 두 가지 방법이 있습니다. 도메인 이름을 사용하고 각 클라이언트에 대해 DNS 서버를 추가하는 것입니다. 그러면 주소는 우리에게 특별히 중요하지 않습니다(k8s의 네트워크 부분과 유사). 그러나 외부 네트워크에는 문제가 있습니다. 주소는 DHCP를 통해 발급될 수도 있습니다. 클라우드 플랫폼의 DNS 서버 및 외부 DNS 서버와의 동기화가 필요합니다. 제 생각에는 그다지 유연하지는 않지만 가능합니다. 또는 두 번째 옵션은 메타데이터를 사용하는 것입니다. 즉, 기계가 이미 주소를 수신한 경우 DHCP 서버가 기계에 어떤 주소를 발행할지 알 수 있도록 기계에 발행된 주소에 대한 정보를 저장합니다. 두 번째 옵션은 자동차에 대한 추가 정보를 저장할 수 있으므로 더 간단하고 유연합니다. 이제 다이어그램에 에이전트 메타데이터를 추가해 보겠습니다.

논의할 가치가 있는 또 다른 문제는 모든 클라이언트가 하나의 외부 네트워크를 사용할 수 있다는 것입니다. 왜냐하면 외부 네트워크가 전체 네트워크에 걸쳐 유효해야 한다면 어려울 것이기 때문입니다. 이러한 네트워크의 할당을 지속적으로 할당하고 제어해야 합니다. 모든 클라이언트에 대해 사전 구성된 단일 외부 네트워크를 사용할 수 있는 기능은 퍼블릭 클라우드를 생성할 때 매우 유용합니다. 이렇게 하면 주소 데이터베이스를 참조하고 각 클라이언트의 외부 네트워크에 대해 고유한 주소 공간을 선택할 필요가 없기 때문에 머신 배포가 더 쉬워집니다. 또한 외부 네트워크를 미리 등록할 수 있으며 배포 시 외부 주소를 클라이언트 시스템과 연결하기만 하면 됩니다.

여기서 NAT가 도움이 됩니다. NAT 변환을 사용하여 클라이언트가 기본 네임스페이스를 통해 외부 세계에 액세스할 수 있도록 하겠습니다. 자, 여기에 작은 문제가 있습니다. 클라이언트 서버가 서버가 아닌 클라이언트 역할을 하는 경우, 즉 연결을 수락하는 것이 아니라 시작하는 경우에 좋습니다. 그러나 우리의 경우에는 그 반대가 될 것입니다. 이 경우 트래픽을 수신할 때 제어 노드가 이 트래픽이 클라이언트 A의 가상 머신 A를 위한 것임을 이해하도록 대상 NAT를 수행해야 합니다. 즉, 외부 주소(예: 100.1.1.1)에서 NAT 변환을 수행해야 함을 의미합니다. .10.0.0.1, 내부 주소 100. 이 경우 모든 클라이언트가 동일한 네트워크를 사용하더라도 내부 격리는 완전히 유지됩니다. 즉, 제어 노드에서 dNAT와 sNAT를 수행해야 합니다. 유동 주소가 있는 단일 네트워크를 사용할지, 외부 네트워크를 사용할지, 아니면 둘 다를 동시에 사용할지는 클라우드로 가져오려는 항목에 따라 다릅니다. 다이어그램에 부동 주소를 추가하지는 않지만 이전에 이미 추가된 외부 네트워크는 그대로 둡니다. 각 클라이언트에는 자체 외부 네트워크가 있습니다(다이어그램에서는 외부 인터페이스에서 VLAN 200 및 XNUMX으로 표시됨).

결과적으로 우리는 어느 정도 유연성은 있지만 아직 내결함성 메커니즘이 없는 흥미롭고 신중한 솔루션을 받았습니다.

첫째, 제어 노드는 단 하나뿐입니다. 이 노드가 실패하면 모든 시스템이 붕괴됩니다. 이 문제를 해결하려면 최소한 3개 노드로 구성된 쿼럼을 만들어야 합니다. 이것을 다이어그램에 추가해 보겠습니다.

당연히 모든 노드는 동기화되며 활성 노드가 떠나면 다른 노드가 그 책임을 대신하게 됩니다.

다음 문제는 가상 머신 디스크입니다. 현재 하이퍼바이저 자체에 저장되어 있으며 하이퍼바이저에 문제가 있는 경우 모든 데이터가 손실됩니다. 디스크가 아니라 전체 서버를 손실하면 습격이 있어도 도움이 되지 않습니다. 이를 위해서는 일종의 저장소에 대한 프런트 엔드 역할을 할 서비스를 만들어야 합니다. 어떤 종류의 스토리지가 될지는 우리에게 특별히 중요하지 않지만 디스크와 노드, 그리고 전체 캐비닛의 장애로부터 데이터를 보호해야 합니다. 여기에는 몇 가지 옵션이 있습니다. 물론 파이버 채널을 사용하는 SAN 네트워크도 있지만 솔직히 말해서 FC는 이미 과거의 유물입니다. 전송 분야의 E1과 유사합니다. 예, 동의합니다. 여전히 사용되지만 그것 없이는 절대 불가능한 경우에만. 따라서 저는 더 흥미로운 다른 대안이 있다는 것을 알기 때문에 2020년에는 FC 네트워크를 자발적으로 구축하지 않을 것입니다. 비록 각자의 한계가 있지만 FC가 우리에게 필요한 전부라고 믿는 사람들이 있을 수 있습니다. 저는 논쟁하지 않겠습니다. 모든 사람은 자신의 의견을 가지고 있습니다. 그러나 내 생각에 가장 흥미로운 해결책은 Ceph와 같은 SDS를 사용하는 것입니다.

Ceph를 사용하면 패리티 검사(raid 5 또는 6과 유사)가 포함된 코드로 시작하여 디스크 위치를 고려하여 다른 디스크에 대한 전체 데이터 복제로 끝나는 다양한 백업 옵션을 갖춘 고가용성 데이터 스토리지 솔루션을 구축할 수 있습니다. 서버, 캐비닛의 서버 등

Ceph를 빌드하려면 3개의 노드가 더 필요합니다. 스토리지와의 상호작용은 블록, 객체 및 파일 스토리지 서비스를 사용하여 네트워크를 통해 수행됩니다. 스키마에 저장소를 추가해 보겠습니다.

참고: 하이퍼컨버지드 컴퓨팅 노드를 만들 수도 있습니다. 이는 ceph 스토리지 전용 노드를 지정하지 않고 하나의 노드에 여러 기능(예: 스토리지+컴퓨팅)을 결합하는 개념입니다. SDS는 우리가 지정한 예약 수준으로 데이터를 예약하므로 동일한 내결함성 체계를 갖게 됩니다. 그러나 하이퍼컨버지드 노드는 항상 타협점입니다. 스토리지 노드는 언뜻 보기에 공기를 가열할 뿐만 아니라(가상 머신이 없기 때문에) SDS 서비스에 CPU 리소스를 소비합니다(실제로 모든 작업을 수행합니다). 노드, 디스크 등 장애 발생 후 복제 및 복구) 즉, 컴퓨팅 노드를 스토리지와 결합하면 컴퓨팅 노드의 성능이 일부 손실됩니다.

이 모든 것은 어떻게든 관리되어야 합니다. 머신, 네트워크, 가상 라우터 등을 생성할 수 있는 것이 필요합니다. 이를 위해 대시보드 역할을 할 제어 노드에 서비스를 추가합니다. 클라이언트는 http/https를 통해 이 포털에 연결하고 필요한 모든 작업을 수행할 수 있습니다(음, 거의).

결과적으로 우리는 이제 내결함성 시스템을 갖게 되었습니다. 이 인프라의 모든 요소는 어떻게든 관리되어야 합니다. Openstack은 각각 특정 기능을 제공하는 프로젝트 집합이라고 이전에 설명했습니다. 보시다시피 구성하고 제어해야 할 요소가 너무 많습니다. 오늘은 네트워크 부분에 대해 이야기하겠습니다.

중성자 아키텍처

OpenStack에서는 가상 머신 포트를 공통 L2 네트워크에 연결하여 서로 다른 L2 네트워크에 위치한 VM 간의 트래픽 라우팅을 보장하는 것은 물론 외부 라우팅을 보장하고 NAT, Floating IP, DHCP 등과 같은 서비스를 제공하는 역할을 담당하는 것이 Neutron입니다.

높은 수준에서 네트워크 서비스(기본 부분)의 작동은 다음과 같이 설명할 수 있습니다.

VM을 시작할 때 네트워크 서비스는 다음을 수행합니다.

1. 특정 VM(또는 포트)에 대한 포트를 생성하고 이에 대해 DHCP 서비스에 알립니다.
2. 새로운 가상 네트워크 장치가 생성됩니다(libvirt를 통해).
3. VM은 1단계에서 생성된 포트에 연결됩니다.

이상하게도 Neutron의 작업은 Linux를 사용해 본 모든 사람에게 친숙한 표준 메커니즘(네임스페이스, iptables, Linux 브리지, openvswitch, conntrack 등)을 기반으로 합니다.

Neutron이 SDN 컨트롤러가 아니라는 점을 즉시 명확히 해야 합니다.

중성자는 여러 개의 상호 연결된 구성 요소로 구성됩니다.

OpenStack-중성자-서버 API를 통해 사용자 요청과 함께 작동하는 데몬입니다. 이 악마는 네트워크 연결 등록에 관여하지 않지만 이에 필요한 정보를 플러그인에 제공하여 원하는 네트워크 요소를 구성합니다. OpenStack 노드의 Neutron 에이전트는 Neutron 서버에 등록됩니다.

Neutron-server는 실제로 Python으로 작성된 애플리케이션으로, 두 부분으로 구성됩니다.

• REST 서비스
• Neutron 플러그인(코어/서비스)

REST 서비스는 다른 구성 요소(예: 일부 정보 제공 요청 등)로부터 API 호출을 수신하도록 설계되었습니다.

플러그인은 API 요청 중에 호출되는 플러그인 소프트웨어 구성 요소/모듈입니다. 즉, 서비스 속성은 플러그인을 통해 발생합니다. 플러그인은 서비스와 루트의 두 가지 유형으로 나뉩니다. 일반적으로 Horse 플러그인은 VM 간의 주소 공간 및 L2 연결 관리를 주로 담당하며 서비스 플러그인은 이미 VPN 또는 FW와 같은 추가 기능을 제공합니다.

예를 들어 현재 사용 가능한 플러그인 목록을 볼 수 있습니다. 여기에

서비스 플러그인은 여러 개 있을 수 있지만 말 플러그인은 하나만 있을 수 있습니다.

오픈스택-중성자-ml2 표준 OpenStack 루트 플러그인입니다. 이 플러그인은 이전 버전과 달리 모듈식 아키텍처를 가지며 연결된 드라이버를 통해 네트워크 서비스를 구성합니다. 플러그인 자체는 실제로 OpenStack이 네트워크 부분에서 갖는 유연성을 제공하므로 잠시 후에 플러그인 자체를 살펴보겠습니다. 루트 플러그인은 교체될 수 있습니다(예를 들어 Contrail Networking이 이러한 교체를 수행함).

RPC 서비스(rabbitmq-server) — 대기열 관리 및 다른 OpenStack 서비스와의 상호 작용은 물론 네트워크 서비스 에이전트 간의 상호 작용을 제공하는 서비스입니다.

네트워크 에이전트 — 네트워크 서비스가 구성되는 각 노드에 위치한 에이전트입니다.

에이전트에는 여러 유형이 있습니다.

주요 대리인은 L2 에이전트. 이러한 에이전트는 제어 노드(더 정확하게는 테넌트에게 서비스를 제공하는 모든 노드)를 포함한 각 하이퍼바이저에서 실행되며 주요 기능은 가상 머신을 공통 L2 네트워크에 연결하고 이벤트가 발생할 때 경고를 생성하는 것입니다( 예를 들어 포트를 비활성화/활성화합니다.

다음으로 덜 중요한 에이전트는 L3 에이전트. 기본적으로 이 에이전트는 네트워크 노드(종종 네트워크 노드가 제어 노드와 결합됨)에서만 실행되며 테넌트 네트워크 간(해당 네트워크와 다른 테넌트의 네트워크 간 모두, 외부 세계에 액세스할 수 있는) 라우팅을 제공합니다. NAT 및 DHCP 서비스). 그러나 DVR(분산 라우터)을 사용하는 경우 컴퓨팅 노드에도 L3 플러그인의 필요성이 나타납니다.

L3 에이전트는 Linux 네임스페이스를 사용하여 각 테넌트에 격리된 자체 네트워크 집합과 트래픽을 라우팅하고 레이어 2 네트워크에 게이트웨이 서비스를 제공하는 가상 라우터 기능을 제공합니다.

데이터베이스 — 네트워크, 서브넷, 포트, 풀 등의 식별자 데이터베이스

실제로 Neutron은 네트워크 엔터티 생성 시 API 요청을 수락하고 요청을 인증하며 RPC(일부 플러그인이나 에이전트에 액세스하는 경우) 또는 REST API(SDN에서 통신하는 경우)를 통해 플러그인을 통해 에이전트에 전송합니다. 요청한 서비스를 구성하는 데 필요한 지침.

이제 테스트 설치(배포 방법과 포함 내용은 나중에 실제 부분에서 살펴보겠습니다)로 돌아가서 각 구성 요소가 어디에 있는지 살펴보겠습니다.

(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$ 

실제로 이것이 뉴트론의 전체 구조입니다. 이제 ML2 플러그인에 시간을 투자할 가치가 있습니다.

모듈형 레이어 2

위에서 언급했듯이 플러그인은 표준 OpenStack 루트 플러그인이며 모듈식 아키텍처를 가지고 있습니다.

ML2 플러그인의 이전 버전은 모놀리식 구조를 갖고 있었기 때문에 한 번의 설치에서 여러 기술을 혼합하여 사용할 수 없었습니다. 예를 들어, openvswitch와 linuxbridge를 동시에 사용할 수 없습니다(첫 번째 또는 두 번째). 이러한 이유로 해당 아키텍처를 갖춘 ML2 플러그인이 만들어졌습니다.

ML2에는 두 가지 구성 요소, 즉 유형 드라이버와 메커니즘 드라이버라는 두 가지 유형의 드라이버가 있습니다.

유형 드라이버 VxLAN, VLAN, GRE 등 네트워크 연결을 구성하는 데 사용할 기술을 결정합니다. 동시에 드라이버는 다양한 기술을 사용할 수 있습니다. 표준 기술은 오버레이 네트워크 및 VLAN 외부 네트워크를 위한 VxLAN 캡슐화입니다.

유형 드라이버에는 다음 네트워크 유형이 포함됩니다.

평면 - 태깅 없는 네트워크
VLAN - 태그가 지정된 네트워크
지방의 — 올인원 설치를 위한 특별한 유형의 네트워크(이러한 설치는 개발자나 교육을 위해 필요함)
GRE — GRE 터널을 사용하는 오버레이 네트워크
VxLAN — VxLAN 터널을 사용하는 오버레이 네트워크

메커니즘 드라이버 유형 드라이버에 지정된 기술의 구성을 보장하는 도구(예: openvswitch, sr-iov, opendaylight, OVN 등)를 정의합니다.

이 드라이버의 구현에 따라 Neutron이 제어하는 ​​에이전트가 사용되거나 L2 네트워크 구성, 라우팅 등과 관련된 모든 문제를 처리하는 외부 SDN 컨트롤러에 대한 연결이 사용됩니다.

예: ML2를 OVS와 함께 사용하는 경우 OVS를 관리하는 각 컴퓨팅 노드에 L2 에이전트가 설치됩니다. 그러나 예를 들어 OVN 또는 OpenDayLight를 사용하는 경우 OVS의 제어는 해당 관할권에 속합니다. Neutron은 루트 플러그인을 통해 컨트롤러에 명령을 제공하고 이미 지시된 대로 수행합니다.

Open vSwitch에 대해 자세히 살펴보겠습니다.

현재 OpenStack의 핵심 구성 요소 중 하나는 Open vSwitch입니다.
Juniper Contrail 또는 Nokia Nuage와 같은 추가 공급업체 SDN 없이 OpenStack을 설치하는 경우 OVS는 클라우드 네트워크의 주요 네트워크 구성 요소이며 iptables, conntrack, 네임스페이스와 함께 본격적인 멀티 테넌시 오버레이 네트워크를 구성할 수 있습니다. 당연히 이 구성 요소는 타사 독점(공급업체) SDN 솔루션을 사용할 때 교체될 수 있습니다.

OVS는 가상화된 환경에서 가상 트래픽 전달자로 사용하도록 설계된 오픈 소스 소프트웨어 스위치입니다.

현재 OVS는 QoS, LACP, VLAN, VxLAN, GENEVE, OpenFlow, DPDK 등과 같은 기술을 포함하는 매우 적절한 기능을 갖추고 있습니다.

참고: OVS는 처음에는 부하가 높은 통신 기능을 위한 소프트 스위치로 생각되지 않았으며 웹 서버나 메일 서버와 같이 대역폭을 덜 요구하는 IT 기능을 위해 설계되었습니다. 그러나 OVS는 추가로 개발되고 있으며 현재 OVS 구현을 통해 성능과 기능이 크게 향상되어 기능이 많이 로드된 통신 사업자가 사용할 수 있습니다. 예를 들어 DPDK 가속을 지원하는 OVS 구현이 있습니다.

알아야 할 OVS의 세 가지 중요한 구성 요소는 다음과 같습니다.

• 커널 모듈 — 제어 요소로부터 수신된 규칙에 따라 트래픽을 처리하는 커널 공간에 위치한 구성 요소입니다.
• v스위치 데몬(ovs-vswitchd)은 커널 모듈 프로그래밍을 담당하는 사용자 공간에서 실행되는 프로세스입니다. 즉, 스위치 작동 논리를 직접적으로 나타냅니다.
• 데이터베이스 서버 - 구성이 저장되는 OVS를 실행하는 각 호스트에 있는 로컬 데이터베이스입니다. SDN 컨트롤러는 OVSDB 프로토콜을 사용하여 이 모듈을 통해 통신할 수 있습니다.

이 모든 기능에는 ovs-vsctl, ovs-appctl, ovs-ofctl 등과 같은 일련의 진단 및 관리 유틸리티가 함께 제공됩니다.

현재 Openstack은 EPC, SBC, HLR 등과 같은 네트워크 기능을 Openstack으로 마이그레이션하기 위해 통신 사업자가 널리 사용하고 있습니다. 일부 기능은 그대로 OVS에 문제 없이 작동할 수 있지만, 예를 들어 EPC는 가입자 트래픽을 처리한 다음 통과합니다. 엄청난 양의 트래픽(현재 트래픽 양은 초당 수백 기가비트에 달함) 당연히 커널 공간을 통해 이러한 트래픽을 유도하는 것은(포워더가 기본적으로 커널 공간에 위치하므로) 최선의 방법은 아닙니다. 따라서 OVS는 커널을 우회하여 NIC에서 사용자 공간으로 트래픽을 전달하기 위해 DPDK 가속 기술을 사용하여 사용자 공간에 완전히 배포되는 경우가 많습니다.

참고: 통신 기능을 위해 배포된 클라우드의 경우 OVS를 우회하는 컴퓨팅 노드에서 직접 스위칭 장비로 트래픽을 출력할 수 있습니다. SR-IOV 및 패스스루 메커니즘이 이 목적으로 사용됩니다.

실제 레이아웃에서는 어떻게 작동하나요?

자, 이제 실용적인 부분으로 넘어가서 그것이 실제로 어떻게 작동하는지 살펴보겠습니다.

먼저 간단한 OpenStack 설치를 배포해 보겠습니다. 실험을 위한 서버 세트가 없기 때문에 가상 머신에서 하나의 물리적 서버에 프로토타입을 조립하겠습니다. 예, 당연히 이러한 솔루션은 상업적 목적에는 적합하지 않지만 Openstack에서 네트워크가 어떻게 작동하는지에 대한 예를 보려면 이러한 설치만으로 눈에 충분합니다. 또한 이러한 설치는 교통 상황 등을 파악할 수 있기 때문에 교육 목적으로 훨씬 더 흥미 롭습니다.

기본적인 부분만 보면 되기 때문에 여러 개의 네트워크를 사용할 수 없고 두 개의 네트워크만 사용하여 모든 것을 키우고, 이 레이아웃의 두 번째 네트워크는 언더클라우드 및 DNS 서버에 대한 액세스에만 독점적으로 사용됩니다. 지금은 외부 네트워크에 대해서는 다루지 않겠습니다. 이는 별도의 대규모 기사에 대한 주제입니다.

그럼 순서대로 시작해 보겠습니다. 첫째, 약간의 이론입니다. TripleO(Openstack on Openstack)를 사용하여 Openstack을 설치하겠습니다. TripleO의 핵심은 언더클라우드라고 하는 OpenStack 올인원(즉, 하나의 노드에)을 설치한 다음 배포된 Openstack의 기능을 사용하여 오버클라우드라고 하는 운영용 Openstack을 설치한다는 것입니다. 언더클라우드는 물리적 서버(베어메탈)(Ironic 프로젝트)를 관리하는 고유한 기능을 사용하여 컴퓨팅, 제어, 스토리지 노드 역할을 수행하는 하이퍼바이저를 프로비저닝합니다. 즉, 우리는 Openstack을 배포하기 위해 타사 도구를 사용하지 않고 Openstack을 사용하여 Openstack을 배포합니다. 설치가 진행될수록 더욱 명확해질 것이므로 여기서 멈추지 않고 앞으로 나아갈 것입니다.

참고: 이 기사에서는 단순화를 위해 내부 OpenStack 네트워크에 네트워크 격리를 사용하지 않았지만 모든 것이 하나의 네트워크만 사용하여 배포되었습니다. 그러나 네트워크 격리 여부는 솔루션의 기본 기능에 영향을 미치지 않습니다. 모든 것이 격리를 사용할 때와 정확히 동일하게 작동하지만 트래픽은 동일한 네트워크에서 흐릅니다. 상업용 설치의 경우 당연히 다른 VLAN과 인터페이스를 사용하여 격리를 사용해야 합니다. 예를 들어, ceph 스토리지 관리 트래픽과 데이터 트래픽 자체(디스크에 대한 시스템 액세스 등)는 격리된 경우 서로 다른 서브넷(스토리지 관리 및 스토리지)을 사용하며 이를 통해 이 트래픽을 분할하여 솔루션의 내결함성을 더욱 강화할 수 있습니다. , 서로 다른 포트를 통해 또는 서로 다른 트래픽에 대해 서로 다른 QoS 프로필을 사용하여 데이터 트래픽이 신호 트래픽을 압박하지 않도록 합니다. 우리의 경우 그들은 동일한 네트워크에 접속할 것이며 실제로 이것이 우리를 어떤 식으로든 제한하지 않습니다.

참고: 가상 머신을 기반으로 하는 가상 환경에서 가상 머신을 실행할 예정이므로 먼저 중첩된 가상화를 활성화해야 합니다.

다음과 같이 중첩된 가상화가 활성화되었는지 여부를 확인할 수 있습니다.

[root@hp-gen9 bormoglotx]# cat /sys/module/kvm_intel/parameters/nested
N
[root@hp-gen9 bormoglotx]# 

문자 N이 보이면 네트워크에서 찾은 가이드에 따라 중첩된 가상화에 대한 지원을 활성화한 것입니다. 예를 들어 이러한 .

가상 머신에서 다음 회로를 조립해야 합니다.

제 경우에는 향후 설치에 포함될 가상 머신을 연결하기 위해(그 중 7개가 있지만 리소스가 많지 않으면 4개로도 가능합니다) OpenvSwitch를 사용했습니다. 하나의 ovs 브리지를 만들고 포트 그룹을 통해 가상 머신을 연결했습니다. 이를 위해 다음과 같은 xml 파일을 만들었습니다.

[root@hp-gen9 ~]# virsh net-dumpxml ovs-network-1        
<network>
  <name>ovs-network-1</name>
  <uuid>7a2e7de7-fc16-4e00-b1ed-4d190133af67</uuid>
  <forward mode='bridge'/>
  <bridge name='ovs-br1'/>
  <virtualport type='openvswitch'/>
  <portgroup name='trunk-1'>
    <vlan trunk='yes'>
      <tag id='100'/>
      <tag id='101'/>
      <tag id='102'/>
    </vlan>
  </portgroup>
  <portgroup name='access-100'>
    <vlan>
      <tag id='100'/>
    </vlan>
  </portgroup>
  <portgroup name='access-101'>
    <vlan>
      <tag id='101'/>
    </vlan>
  </portgroup>
</network>

여기에는 두 개의 액세스와 하나의 트렁크 등 세 개의 포트 그룹이 선언되어 있습니다(후자는 DNS 서버에 필요했지만 이 그룹 없이 수행하거나 호스트 시스템에 설치할 수 있습니다. 둘 중 더 편리한 쪽). 다음으로 이 템플릿을 사용하여 virsh net-define을 통해 선언합니다.

virsh net-define ovs-network-1.xml 
virsh net-start ovs-network-1 
virsh net-autostart ovs-network-1 

이제 하이퍼바이저 포트 구성을 편집합니다.

[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ens1f0   
TYPE=Ethernet
NAME=ens1f0
DEVICE=ens1f0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=ovs-br1
ONBOOT=yes
OVS_OPTIONS="trunk=100,101,102"
[root@hp-gen9 ~]
[root@hp-gen9 ~]# cat /etc/sysconfig/network-scripts/ifcfg-ovs-br1 
DEVICE=ovs-br1
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
ONBOOT=yes
IPADDR=192.168.255.200
PREFIX=24
[root@hp-gen9 ~]# 

참고: 이 시나리오에서는 VLAN 태그가 없기 때문에 포트 ovs-br1의 주소에 액세스할 수 없습니다. 이 문제를 해결하려면 sudo ovs-vsctl set port ovs-br1 tag=100 명령을 실행해야 합니다. 그러나 재부팅 후에는 이 태그가 사라집니다. (누군가 이 태그를 그대로 유지하는 방법을 알고 계시다면 매우 감사하겠습니다.) 하지만 이 주소는 설치 중에만 필요하고 Openstack이 완전히 배포된 후에는 필요하지 않기 때문에 그다지 중요하지 않습니다.

다음으로 언더클라우드 머신을 생성합니다.

virt-install  -n undercloud --description "undercloud"  --os-type=Linux  --os-variant=centos7.0  --ram=8192  --vcpus=8  --disk path=/var/lib/libvirt/images/undercloud.qcow2,bus=virtio,size=40,format=qcow2 --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=access-101 --graphics none  --location /var/lib/libvirt/boot/CentOS-7-x86_64-Minimal-2003.iso --extra-args console=ttyS0

설치하는 동안 컴퓨터 이름, 비밀번호, 사용자, ntp 서버 등과 같은 필요한 모든 매개 변수를 설정하고 즉시 포트를 구성할 수 있지만 개인적으로는 설치 후 다음을 통해 컴퓨터에 로그인하는 것이 더 쉽습니다. 콘솔을 열고 필요한 파일을 수정하세요. 기성 이미지가 이미 있는 경우 이를 사용하거나 제가 한 것처럼 최소 Centos 7 이미지를 다운로드하여 VM을 설치하는 데 사용할 수 있습니다.

성공적으로 설치되면 언더클라우드를 설치할 수 있는 가상 머신이 있어야 합니다.

[root@hp-gen9 bormoglotx]# virsh list
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 62    undercloud                     running

먼저 설치 프로세스에 필요한 도구를 설치합니다.

sudo yum update -y
sudo yum install -y net-tools
sudo yum install -y wget
sudo yum install -y ipmitool

언더클라우드 설치

스택 사용자를 생성하고 비밀번호를 설정한 후 sudoer에 추가하고 비밀번호를 입력하지 않고도 sudo를 통해 루트 명령을 실행할 수 있는 기능을 제공합니다.

useradd stack
passwd stack

echo “stack ALL=(root) NOPASSWD:ALL” > /etc/sudoers.d/stack
chmod 0440 /etc/sudoers.d/stack

이제 호스트 파일에 전체 언더클라우드 이름을 지정합니다.

vi /etc/hosts

127.0.0.1   undercloud.openstack.rnd localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

다음으로 리포지토리를 추가하고 필요한 소프트웨어를 설치합니다.

sudo yum install -y https://trunk.rdoproject.org/centos7/current/python2-tripleo-repos-0.0.1-0.20200409224957.8bac392.el7.noarch.rpm
sudo -E tripleo-repos -b queens current
sudo -E tripleo-repos -b queens current ceph
sudo yum install -y python-tripleoclient
sudo yum install -y ceph-ansible

참고: ceph를 설치할 계획이 없다면 ceph 관련 명령을 입력할 필요가 없습니다. 저는 Queens 릴리스를 사용했지만 원하는 다른 릴리스를 사용해도 됩니다.

그런 다음 언더클라우드 구성 파일을 사용자의 홈 디렉터리 스택에 복사합니다.

cp /usr/share/instack-undercloud/undercloud.conf.sample ~/undercloud.conf

이제 이 파일을 수정하여 설치에 맞게 조정해야 합니다.

파일 시작 부분에 다음 줄을 추가해야 합니다.

vi undercloud.conf
[DEFAULT]
undercloud_hostname = undercloud.openstack.rnd
local_ip = 192.168.255.1/24
network_gateway = 192.168.255.1
undercloud_public_host = 192.168.255.2
undercloud_admin_host = 192.168.255.3
undercloud_nameservers = 192.168.255.253
generate_service_certificate = false
local_interface = eth0
local_mtu = 1450
network_cidr = 192.168.255.0/24
masquerade = true
masquerade_network = 192.168.255.0/24
dhcp_start = 192.168.255.11
dhcp_end = 192.168.255.50
inspection_iprange = 192.168.255.51,192.168.255.100
scheduler_max_attempts = 10

이제 설정을 살펴보겠습니다.

undercloud_hostname — 언더클라우드 서버의 전체 이름은 DNS 서버의 항목과 일치해야 합니다.

local_ip — 네트워크 프로비저닝을 위한 로컬 언더클라우드 주소

네트워크_게이트웨이 — 오버클라우드 노드 설치 중 외부 세계에 액세스하기 위한 게이트웨이 역할을 하는 동일한 로컬 주소도 로컬 IP와 일치합니다.

undercloud_public_host — 외부 API 주소, 프로비저닝 네트워크의 무료 주소가 할당됩니다.

undercloud_admin_host 내부 API 주소, 프로비저닝 네트워크의 무료 주소가 할당됩니다.

undercloud_nameservers - DNS 서버

generate_service_certificate - 이 줄은 현재 예에서 매우 중요합니다. false로 설정하지 않으면 설치 중에 오류가 발생하고 문제는 Red Hat 버그 추적기에 설명되어 있기 때문입니다.

local_interface 네트워크 프로비저닝의 인터페이스. 이 인터페이스는 언더클라우드 배포 중에 재구성되므로 언더클라우드에 두 개의 인터페이스가 필요합니다. 하나는 액세스용이고 다른 하나는 프로비저닝용입니다.

local_mtu — MTU. 테스트 연구소가 있고 OVS 스위치 포트의 MTU가 1500이므로 VxLAN에 캡슐화된 패킷이 통과할 수 있도록 이를 1450으로 설정해야 합니다.

network_cidr — 네트워크 프로비저닝

가장 무도회 — NAT를 사용하여 외부 네트워크에 액세스

가장 무도회_네트워크 - NAT가 적용될 네트워크

dhcp_start — 오버클라우드 배포 중 노드에 주소가 할당될 주소 풀의 시작 주소

dhcp_end — 오버클라우드 배포 중 노드에 주소가 할당될 주소 풀의 최종 주소

검사_iprange — 내부 조사에 필요한 주소 풀(위 풀과 중복되어서는 안 됨)

Scheduler_max_attempts — 오버클라우드 설치를 위한 최대 시도 횟수(노드 수보다 크거나 같아야 함)

파일을 설명한 후 언더클라우드를 배포하라는 명령을 내릴 수 있습니다.

openstack undercloud install

다리미에 따라 절차는 10~30분 정도 소요됩니다. 최종적으로 다음과 같은 출력이 표시됩니다.

vi undercloud.conf
2020-08-13 23:13:12,668 INFO: 
#############################################################################
Undercloud install complete.

The file containing this installation's passwords is at
/home/stack/undercloud-passwords.conf.

There is also a stackrc file at /home/stack/stackrc.

These files are needed to interact with the OpenStack services, and should be
secured.

#############################################################################

이 출력은 언더클라우드가 성공적으로 설치되었음을 나타냅니다. 이제 언더클라우드의 상태를 확인하고 오버클라우드 설치를 진행할 수 있습니다.

ifconfig 출력을 보면 새로운 브리지 인터페이스가 나타난 것을 볼 수 있습니다.

[stack@undercloud ~]$ ifconfig
br-ctlplane: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.1  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe2c:89e  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:2c:08:9e  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1095 (1.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20  bytes 1292 (1.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

이제 이 인터페이스를 통해 오버클라우드 배포가 수행됩니다.

아래 출력에서 ​​하나의 노드에 모든 서비스가 있음을 확인할 수 있습니다.

(undercloud) [stack@undercloud ~]$ openstack host list
+--------------------------+-----------+----------+
| Host Name                | Service   | Zone     |
+--------------------------+-----------+----------+
| undercloud.openstack.rnd | conductor | internal |
| undercloud.openstack.rnd | scheduler | internal |
| undercloud.openstack.rnd | compute   | nova     |
+--------------------------+-----------+----------+

언더클라우드 네트워크 부분의 구성은 다음과 같습니다.

(undercloud) [stack@undercloud ~]$ python -m json.tool /etc/os-net-config/config.json 
{
    "network_config": [
        {
            "addresses": [
                {
                    "ip_netmask": "192.168.255.1/24"
                }
            ],
            "members": [
                {
                    "dns_servers": [
                        "192.168.255.253"
                    ],
                    "mtu": 1450,
                    "name": "eth0",
                    "primary": "true",
                    "type": "interface"
                }
            ],
            "mtu": 1450,
            "name": "br-ctlplane",
            "ovs_extra": [
                "br-set-external-id br-ctlplane bridge-id br-ctlplane"
            ],
            "routes": [],
            "type": "ovs_bridge"
        }
    ]
}
(undercloud) [stack@undercloud ~]$

오버클라우드 설치

현재는 언더클라우드만 있고 오버클라우드를 구성할 노드가 충분하지 않습니다. 따라서 먼저 필요한 가상 머신을 배포해 보겠습니다. 배포 중에 언더클라우드 자체가 오버클라우드 머신에 OS와 필요한 소프트웨어를 설치합니다. 즉, 머신을 완전히 배포할 필요는 없지만 머신에 대한 디스크(또는 디스크)를 생성하고 해당 매개변수를 결정하기만 하면 됩니다. 실제로 우리는 OS가 설치되지 않은 베어 서버를 갖게 됩니다.

가상 머신의 디스크가 있는 폴더로 이동하여 필요한 크기의 디스크를 생성해 보겠습니다.

cd /var/lib/libvirt/images/
qemu-img create -f qcow2 -o preallocation=metadata control-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-1.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata compute-2.qcow2 60G
qemu-img create -f qcow2 -o preallocation=metadata storage-1.qcow2 160G
qemu-img create -f qcow2 -o preallocation=metadata storage-2.qcow2 160G

우리는 루트로 작업하고 있으므로 권한 문제가 발생하지 않도록 이러한 디스크의 소유자를 변경해야 합니다.

[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 root root  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 root root 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:07 undercloud.qcow2
[root@hp-gen9 images]# 
[root@hp-gen9 images]# 
[root@hp-gen9 images]# chown qemu:qemu /var/lib/libvirt/images/*qcow2
[root@hp-gen9 images]# ls -lh
total 5.8G
drwxr-xr-x. 2 qemu qemu 4.0K Aug 13 16:15 backups
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-1.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 compute-2.qcow2
-rw-r--r--. 1 qemu qemu  61G Aug 14 03:07 control-1.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:03 dns-server.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-1.qcow2
-rw-r--r--. 1 qemu qemu 161G Aug 14 03:07 storage-2.qcow2
-rw-------. 1 qemu qemu  41G Aug 14 03:08 undercloud.qcow2
[root@hp-gen9 images]# 

참고: 연구하기 위해 ceph를 설치할 계획이 없다면 명령은 최소 3개의 디스크가 포함된 최소 XNUMX개의 노드를 생성하지 않지만 템플릿에는 가상 디스크 vda, vdb 등이 사용될 것임을 나타냅니다.

좋습니다. 이제 다음 머신을 모두 정의해야 합니다.

virt-install --name control-1 --ram 32768 --vcpus 8 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/control-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --network network:ovs-network-1,model=virtio,portgroup=trunk-1 --dry-run --print-xml > /tmp/control-1.xml  

virt-install --name storage-1 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-1.xml  

virt-install --name storage-2 --ram 16384 --vcpus 4 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/storage-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/storage-2.xml  

virt-install --name compute-1 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-1.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-1.xml  

virt-install --name compute-2 --ram 32768 --vcpus 12 --os-variant centos7.0 --disk path=/var/lib/libvirt/images/compute-2.qcow2,device=disk,bus=virtio,format=qcow2 --noautoconsole --vnc  --network network:ovs-network-1,model=virtio,portgroup=access-100 --dry-run --print-xml > /tmp/compute-2.xml 

마지막에는 /tmp/ 폴더의 각 시스템에 대한 설명이 포함된 xml 파일을 생성하는 -print-xml > /tmp/storage-1.xml 명령이 있습니다. 이를 추가하지 않으면 가상 머신을 식별할 수 있습니다.

이제 virsh에서 이러한 모든 머신을 정의해야 합니다.

virsh define --file /tmp/control-1.xml
virsh define --file /tmp/compute-1.xml
virsh define --file /tmp/compute-2.xml
virsh define --file /tmp/storage-1.xml
virsh define --file /tmp/storage-2.xml

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

이제 약간의 차이가 있습니다. TripleO는 설치 및 검사 중에 IPMI를 사용하여 서버를 관리합니다.

자체 검사는 노드를 추가로 프로비저닝하는 데 필요한 매개변수를 얻기 위해 하드웨어를 검사하는 프로세스입니다. 자체 검사는 베어메탈 서버와 작동하도록 설계된 서비스인 ironic을 사용하여 수행됩니다.

그러나 여기에 문제가 있습니다. 하드웨어 IPMI 서버에는 별도의 포트(또는 공유 포트, 그러나 중요하지 않음)가 있지만 가상 머신에는 그러한 포트가 없습니다. 여기서 IPMI 포트를 에뮬레이트할 수 있는 유틸리티인 vbmc라는 도구가 도움이 됩니다. 이 뉘앙스는 특히 ESXI 하이퍼바이저에 이러한 실험실을 설정하려는 사람들에게 주목할 가치가 있습니다. 솔직히 말해서 vbmc와 유사한 것이 있는지 모르므로 모든 것을 배포하기 전에 이 문제에 대해 생각해 볼 가치가 있습니다. .

vbmc를 설치합니다:

yum install yum install python2-virtualbmc

OS가 패키지를 찾을 수 없으면 저장소를 추가하십시오.

yum install -y https://www.rdoproject.org/repos/rdo-release.rpm

이제 유틸리티를 설정합니다. 여기의 모든 것은 불명예스러울 정도로 진부합니다. 이제 vbmc 목록에 서버가 없다는 것이 논리적입니다.

[root@hp-gen9 ~]# vbmc list

[root@hp-gen9 ~]# 

표시하려면 다음과 같이 수동으로 선언해야 합니다.

[root@hp-gen9 ~]# vbmc add control-1 --port 7001 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-1 --port 7002 --username admin --password admin
[root@hp-gen9 ~]# vbmc add storage-2 --port 7003 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-1 --port 7004 --username admin --password admin
[root@hp-gen9 ~]# vbmc add compute-2 --port 7005 --username admin --password admin
[root@hp-gen9 ~]#
[root@hp-gen9 ~]# vbmc list
+-------------+--------+---------+------+
| Domain name | Status | Address | Port |
+-------------+--------+---------+------+
| compute-1   | down   | ::      | 7004 |
| compute-2   | down   | ::      | 7005 |
| control-1   | down   | ::      | 7001 |
| storage-1   | down   | ::      | 7002 |
| storage-2   | down   | ::      | 7003 |
+-------------+--------+---------+------+
[root@hp-gen9 ~]#

설명 없이도 명령 구문이 명확하다고 생각합니다. 그러나 현재로서는 모든 세션이 DOWN 상태입니다. UP 상태로 이동하려면 다음을 활성화해야 합니다.

[root@hp-gen9 ~]# vbmc start control-1
2020-08-14 03:15:57,826.826 13149 INFO VirtualBMC [-] Started vBMC instance for domain control-1
[root@hp-gen9 ~]# vbmc start storage-1 
2020-08-14 03:15:58,316.316 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-1
[root@hp-gen9 ~]# vbmc start storage-2
2020-08-14 03:15:58,851.851 13149 INFO VirtualBMC [-] Started vBMC instance for domain storage-2
[root@hp-gen9 ~]# vbmc start compute-1
2020-08-14 03:15:59,307.307 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-1
[root@hp-gen9 ~]# vbmc start compute-2
2020-08-14 03:15:59,712.712 13149 INFO VirtualBMC [-] Started vBMC instance for domain compute-2
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# 
[root@hp-gen9 ~]# vbmc list
+-------------+---------+---------+------+
| Domain name | Status  | Address | Port |
+-------------+---------+---------+------+
| compute-1   | running | ::      | 7004 |
| compute-2   | running | ::      | 7005 |
| control-1   | running | ::      | 7001 |
| storage-1   | running | ::      | 7002 |
| storage-2   | running | ::      | 7003 |
+-------------+---------+---------+------+
[root@hp-gen9 ~]#

마지막으로 방화벽 규칙을 수정해야 합니다(또는 완전히 비활성화해야 합니다).

firewall-cmd --zone=public --add-port=7001/udp --permanent
firewall-cmd --zone=public --add-port=7002/udp --permanent
firewall-cmd --zone=public --add-port=7003/udp --permanent
firewall-cmd --zone=public --add-port=7004/udp --permanent
firewall-cmd --zone=public --add-port=7005/udp --permanent
firewall-cmd --reload

이제 언더클라우드에 가서 모든 것이 제대로 작동하는지 확인해 보겠습니다. 호스트 시스템의 주소는 192.168.255.200입니다. 언더클라우드에서는 배포 준비 중에 필요한 ipmitool 패키지를 추가했습니다.

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status          
Chassis Power is off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power on
Chassis Power Control: Up/On
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list 
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 65    control-1                      running

보시다시피 vbmc를 통해 제어 노드를 성공적으로 시작했습니다. 이제 끄고 계속 진행해 보겠습니다.

[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power off
Chassis Power Control: Down/Off
[stack@undercloud ~]$ ipmitool -I lanplus -U admin -P admin -H 192.168.255.200 -p 7001 power status
Chassis Power is off
[stack@undercloud ~]$ 

[root@hp-gen9 ~]# virsh list --all
 Id    Name                           State
----------------------------------------------------
 6     dns-server                     running
 64    undercloud                     running
 -     compute-1                      shut off
 -     compute-2                      shut off
 -     control-1                      shut off
 -     storage-1                      shut off
 -     storage-2                      shut off

[root@hp-gen9 ~]#

다음 단계는 오버클라우드가 설치될 노드를 검사하는 것입니다. 이렇게 하려면 노드에 대한 설명이 포함된 json 파일을 준비해야 합니다. 베어 서버에 설치하는 것과 달리 파일은 각 시스템에 대해 vbmc가 실행되는 포트를 나타냅니다.

[root@hp-gen9 ~]# virsh domiflist --domain control-1 
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:20:a2:2f
-          network    ovs-network-1 virtio      52:54:00:3f:87:9f

[root@hp-gen9 ~]# virsh domiflist --domain compute-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:98:e9:d6

[root@hp-gen9 ~]# virsh domiflist --domain compute-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:6a:ea:be

[root@hp-gen9 ~]# virsh domiflist --domain storage-1
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:79:0b:cb

[root@hp-gen9 ~]# virsh domiflist --domain storage-2
Interface  Type       Source     Model       MAC
-------------------------------------------------------
-          network    ovs-network-1 virtio      52:54:00:a7:fe:27

참고: 제어 노드에는 두 개의 인터페이스가 있지만 이 경우에는 중요하지 않습니다. 이 설치에서는 인터페이스 하나로 충분합니다.

이제 json 파일을 준비합니다. 프로비저닝이 수행될 포트의 Poppy 주소, 노드의 매개변수를 표시하고 이름을 지정하고 ipmi에 도달하는 방법을 표시해야 합니다.

{
    "nodes":[
        {
            "mac":[
                "52:54:00:20:a2:2f"
            ],
            "cpu":"8",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"control-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7001"
        },
        {
            "mac":[
                "52:54:00:79:0b:cb"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7002"
        },
        {
            "mac":[
                "52:54:00:a7:fe:27"
            ],
            "cpu":"4",
            "memory":"16384",
            "disk":"160",
            "arch":"x86_64",
            "name":"storage-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7003"
        },
        {
            "mac":[
                "52:54:00:98:e9:d6"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-1",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7004"
        },
        {
            "mac":[
                "52:54:00:6a:ea:be"
            ],
            "cpu":"12",
            "memory":"32768",
            "disk":"60",
            "arch":"x86_64",
            "name":"compute-2",
            "pm_type":"pxe_ipmitool",
            "pm_user":"admin",
            "pm_password":"admin",
            "pm_addr":"192.168.255.200",
            "pm_port":"7005"
        }
    ]
}

이제 아이러니한 이미지를 준비해야 합니다. 이렇게 하려면 wget을 통해 다운로드하고 설치하십시오.

(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/overcloud-full.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ sudo wget https://images.rdoproject.org/queens/delorean/current-tripleo-rdo/ironic-python-agent.tar --no-check-certificate
(undercloud) [stack@undercloud ~]$ ls -lh
total 1.9G
-rw-r--r--. 1 stack stack 447M Aug 14 10:26 ironic-python-agent.tar
-rw-r--r--. 1 stack stack 1.5G Aug 14 10:26 overcloud-full.tar
-rw-------. 1 stack stack  916 Aug 13 23:10 stackrc
-rw-r--r--. 1 stack stack  15K Aug 13 22:50 undercloud.conf
-rw-------. 1 stack stack 2.0K Aug 13 22:50 undercloud-passwords.conf
(undercloud) [stack@undercloud ~]$ mkdir images/
(undercloud) [stack@undercloud ~]$ tar -xpvf ironic-python-agent.tar -C ~/images/
ironic-python-agent.initramfs
ironic-python-agent.kernel
(undercloud) [stack@undercloud ~]$ tar -xpvf overcloud-full.tar -C ~/images/                       
overcloud-full.qcow2
overcloud-full.initrd
overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ ls -lh images/
total 1.9G
-rw-rw-r--. 1 stack stack 441M Aug 12 17:24 ironic-python-agent.initramfs
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:24 ironic-python-agent.kernel
-rw-r--r--. 1 stack stack  53M Aug 12 17:14 overcloud-full.initrd
-rw-r--r--. 1 stack stack 1.4G Aug 12 17:18 overcloud-full.qcow2
-rwxr-xr-x. 1 stack stack 6.5M Aug 12 17:14 overcloud-full.vmlinuz
(undercloud) [stack@undercloud ~]$

언더클라우드에 이미지 업로드:

(undercloud) [stack@undercloud ~]$ openstack overcloud image upload --image-path ~/images/
Image "overcloud-full-vmlinuz" was uploaded.
+--------------------------------------+------------------------+-------------+---------+--------+
|                  ID                  |          Name          | Disk Format |   Size  | Status |
+--------------------------------------+------------------------+-------------+---------+--------+
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz |     aki     | 6761064 | active |
+--------------------------------------+------------------------+-------------+---------+--------+
Image "overcloud-full-initrd" was uploaded.
+--------------------------------------+-----------------------+-------------+----------+--------+
|                  ID                  |          Name         | Disk Format |   Size   | Status |
+--------------------------------------+-----------------------+-------------+----------+--------+
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd |     ari     | 55183045 | active |
+--------------------------------------+-----------------------+-------------+----------+--------+
Image "overcloud-full" was uploaded.
+--------------------------------------+----------------+-------------+------------+--------+
|                  ID                  |      Name      | Disk Format |    Size    | Status |
+--------------------------------------+----------------+-------------+------------+--------+
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full |    qcow2    | 1487475712 | active |
+--------------------------------------+----------------+-------------+------------+--------+
Image "bm-deploy-kernel" was uploaded.
+--------------------------------------+------------------+-------------+---------+--------+
|                  ID                  |       Name       | Disk Format |   Size  | Status |
+--------------------------------------+------------------+-------------+---------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel |     aki     | 6761064 | active |
+--------------------------------------+------------------+-------------+---------+--------+
Image "bm-deploy-ramdisk" was uploaded.
+--------------------------------------+-------------------+-------------+-----------+--------+
|                  ID                  |        Name       | Disk Format |    Size   | Status |
+--------------------------------------+-------------------+-------------+-----------+--------+
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk |     ari     | 461759376 | active |
+--------------------------------------+-------------------+-------------+-----------+--------+
(undercloud) [stack@undercloud ~]$

모든 이미지가 로드되었는지 확인 중

(undercloud) [stack@undercloud ~]$  openstack image list
+--------------------------------------+------------------------+--------+
| ID                                   | Name                   | Status |
+--------------------------------------+------------------------+--------+
| e413aa78-e38f-404c-bbaf-93e582a8e67f | bm-deploy-kernel       | active |
| 5cf3aba4-0e50-45d3-929f-27f025dd6ce3 | bm-deploy-ramdisk      | active |
| a2f2096d-c9d7-429a-b866-c7543c02a380 | overcloud-full         | active |
| 949984e0-4932-4e71-af43-d67a38c3dc89 | overcloud-full-initrd  | active |
| c2553770-3e0f-4750-b46b-138855b5c385 | overcloud-full-vmlinuz | active |
+--------------------------------------+------------------------+--------+
(undercloud) [stack@undercloud ~]$

한 가지 더 - DNS 서버를 추가해야 합니다.

(undercloud) [stack@undercloud ~]$ openstack subnet list
+--------------------------------------+-----------------+--------------------------------------+------------------+
| ID                                   | Name            | Network                              | Subnet           |
+--------------------------------------+-----------------+--------------------------------------+------------------+
| f45dea46-4066-42aa-a3c4-6f84b8120cab | ctlplane-subnet | 6ca013dc-41c2-42d8-9d69-542afad53392 | 192.168.255.0/24 |
+--------------------------------------+-----------------+--------------------------------------+------------------+
(undercloud) [stack@undercloud ~]$ openstack subnet show f45dea46-4066-42aa-a3c4-6f84b8120cab
+-------------------+-----------------------------------------------------------+
| Field             | Value                                                     |
+-------------------+-----------------------------------------------------------+
| allocation_pools  | 192.168.255.11-192.168.255.50                             |
| cidr              | 192.168.255.0/24                                          |
| created_at        | 2020-08-13T20:10:37Z                                      |
| description       |                                                           |
| dns_nameservers   |                                                           |
| enable_dhcp       | True                                                      |
| gateway_ip        | 192.168.255.1                                             |
| host_routes       | destination='169.254.169.254/32', gateway='192.168.255.1' |
| id                | f45dea46-4066-42aa-a3c4-6f84b8120cab                      |
| ip_version        | 4                                                         |
| ipv6_address_mode | None                                                      |
| ipv6_ra_mode      | None                                                      |
| name              | ctlplane-subnet                                           |
| network_id        | 6ca013dc-41c2-42d8-9d69-542afad53392                      |
| prefix_length     | None                                                      |
| project_id        | a844ccfcdb2745b198dde3e1b28c40a3                          |
| revision_number   | 0                                                         |
| segment_id        | None                                                      |
| service_types     |                                                           |
| subnetpool_id     | None                                                      |
| tags              |                                                           |
| updated_at        | 2020-08-13T20:10:37Z                                      |
+-------------------+-----------------------------------------------------------+
(undercloud) [stack@undercloud ~]$ 
(undercloud) [stack@undercloud ~]$ neutron subnet-update f45dea46-4066-42aa-a3c4-6f84b8120cab --dns-nameserver 192.168.255.253                                    
neutron CLI is deprecated and will be removed in the future. Use openstack CLI instead.
Updated subnet: f45dea46-4066-42aa-a3c4-6f84b8120cab
(undercloud) [stack@undercloud ~]$

이제 우리는 자기 성찰 명령을 내릴 수 있습니다:

(undercloud) [stack@undercloud ~]$ openstack overcloud node import --introspect --provide inspection.json 
Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: d57456a3-d8ed-479c-9a90-dff7c752d0ec
Waiting for messages on queue 'tripleo' with no timeout.


5 node(s) successfully moved to the "manageable" state.
Successfully registered node UUID b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
Successfully registered node UUID b89a72a3-6bb7-429a-93bc-48393d225838
Successfully registered node UUID 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
Successfully registered node UUID bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
Successfully registered node UUID 766ab623-464c-423d-a529-d9afb69d1167
Waiting for introspection to finish...
Started Mistral Workflow tripleo.baremetal.v1.introspect. Execution ID: 6b4d08ae-94c3-4a10-ab63-7634ec198a79
Waiting for messages on queue 'tripleo' with no timeout.
Introspection of node b89a72a3-6bb7-429a-93bc-48393d225838 completed. Status:SUCCESS. Errors:None
Introspection of node 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e completed. Status:SUCCESS. Errors:None
Introspection of node bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 completed. Status:SUCCESS. Errors:None
Introspection of node 766ab623-464c-423d-a529-d9afb69d1167 completed. Status:SUCCESS. Errors:None
Introspection of node b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 completed. Status:SUCCESS. Errors:None
Successfully introspected 5 node(s).
Started Mistral Workflow tripleo.baremetal.v1.provide. Execution ID: f5594736-edcf-4927-a8a0-2a7bf806a59a
Waiting for messages on queue 'tripleo' with no timeout.
5 node(s) successfully moved to the "available" state.
(undercloud) [stack@undercloud ~]$

출력에서 볼 수 있듯이 모든 것이 오류 없이 완료되었습니다. 모든 노드가 사용 가능한 상태인지 확인해 보겠습니다.

(undercloud) [stack@undercloud ~]$ openstack baremetal node list
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| UUID                                 | Name      | Instance UUID | Power State | Provisioning State | Maintenance |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | None          | power off   | available          | False       |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | None          | power off   | available          | False       |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | None          | power off   | available          | False       |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | None          | power off   | available          | False       |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | None          | power off   | available          | False       |
+--------------------------------------+-----------+---------------+-------------+--------------------+-------------+
(undercloud) [stack@undercloud ~]$ 

노드가 일반적으로 관리 가능한 다른 상태에 있는 경우 문제가 발생한 것이므로 로그를 보고 이러한 일이 발생한 이유를 파악해야 합니다. 이 시나리오에서는 가상화를 사용하고 있으며 가상 머신 또는 vbmc 사용과 관련된 버그가 있을 수 있다는 점을 명심하세요.

다음으로, 어떤 노드가 어떤 기능을 수행하는지 표시해야 합니다. 즉, 노드가 배포될 프로필을 표시해야 합니다.

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | None            |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | None            |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | None            |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | None            |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | None            |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| ID                                   | Name          |  RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
| 168af640-7f40-42c7-91b2-989abc5c5d8f | swift-storage | 4096 |   40 |         0 |     1 | True      |
| 52148d1b-492e-48b4-b5fc-772849dd1b78 | baremetal     | 4096 |   40 |         0 |     1 | True      |
| 56e66542-ae60-416d-863e-0cb192d01b09 | control       | 4096 |   40 |         0 |     1 | True      |
| af6796e1-d0c4-4bfe-898c-532be194f7ac | block-storage | 4096 |   40 |         0 |     1 | True      |
| e4d50fdd-0034-446b-b72c-9da19b16c2df | compute       | 4096 |   40 |         0 |     1 | True      |
| fc2e3acf-7fca-4901-9eee-4a4d6ef0265d | ceph-storage  | 4096 |   40 |         0 |     1 | True      |
+--------------------------------------+---------------+------+------+-----------+-------+-----------+
(undercloud) [stack@undercloud ~]$

각 노드에 대한 프로필을 지정합니다.

openstack baremetal node set --property capabilities='profile:control,boot_option:local' b4b2cf4a-b7ca-4095-af13-cc83be21c4f5
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' b89a72a3-6bb7-429a-93bc-48393d225838
openstack baremetal node set --property capabilities='profile:ceph-storage,boot_option:local' 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8
openstack baremetal node set --property capabilities='profile:compute,boot_option:local' 766ab623-464c-423d-a529-d9afb69d1167

모든 작업을 올바르게 수행했는지 확인해 보겠습니다.

(undercloud) [stack@undercloud ~]$ openstack overcloud profiles list
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| Node UUID                            | Node Name | Provision State | Current Profile | Possible Profiles |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
| b4b2cf4a-b7ca-4095-af13-cc83be21c4f5 | control-1 | available       | control         |                   |
| b89a72a3-6bb7-429a-93bc-48393d225838 | storage-1 | available       | ceph-storage    |                   |
| 20a16cc0-e0ce-4d88-8f17-eb0ce7b4d69e | storage-2 | available       | ceph-storage    |                   |
| bfc1eb98-a17a-4a70-b0b6-6c0db0eac8e8 | compute-1 | available       | compute         |                   |
| 766ab623-464c-423d-a529-d9afb69d1167 | compute-2 | available       | compute         |                   |
+--------------------------------------+-----------+-----------------+-----------------+-------------------+
(undercloud) [stack@undercloud ~]$

모든 것이 정확하면 오버클라우드를 배포하라는 명령을 내립니다.

openstack overcloud deploy --templates --control-scale 1 --compute-scale 2  --ceph-storage-scale 2 --control-flavor control --compute-flavor compute  --ceph-storage-flavor ceph-storage --libvirt-type qemu

실제 설치에서는 사용자 정의된 템플릿이 자연스럽게 사용됩니다. 우리의 경우 템플릿의 각 편집 내용을 설명해야 하므로 프로세스가 매우 복잡해집니다. 앞서 작성한 것처럼 간단한 설치만으로도 작동 방식을 확인할 수 있습니다.

참고: 이 경우 중첩된 가상화를 사용하므로 --libvirt-type qemu 변수가 필요합니다. 그렇지 않으면 가상 머신을 실행할 수 없습니다.

이제 약 한 시간 또는 그 이상(하드웨어 기능에 따라)이 있으며 이 시간이 지나면 다음 메시지가 표시되기를 바랄 뿐입니다.

2020-08-14 08:39:21Z [overcloud]: CREATE_COMPLETE  Stack CREATE completed successfully

 Stack overcloud CREATE_COMPLETE 

Host 192.168.255.21 not found in /home/stack/.ssh/known_hosts
Started Mistral Workflow tripleo.deployment.v1.get_horizon_url. Execution ID: fcb996cd-6a19-482b-b755-2ca0c08069a9
Overcloud Endpoint: http://192.168.255.21:5000/
Overcloud Horizon Dashboard URL: http://192.168.255.21:80/dashboard
Overcloud rc file: /home/stack/overcloudrc
Overcloud Deployed
(undercloud) [stack@undercloud ~]$

이제 연구, 실험 등을 할 수 있는 거의 모든 기능을 갖춘 OpenStack 버전이 생겼습니다.

모든 것이 제대로 작동하는지 확인해 보겠습니다. 사용자의 홈 디렉터리 스택에는 두 개의 파일, 즉 stackrc(언더클라우드 관리용)와 두 번째 overcloudrc(오버클라우드 관리용)가 있습니다. 이러한 파일에는 인증에 필요한 정보가 포함되어 있으므로 소스로 지정해야 합니다.

(undercloud) [stack@undercloud ~]$ openstack server list
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| ID                                   | Name                    | Status | Networks                | Image          | Flavor       |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
| fd7d36f4-ce87-4b9a-93b0-add2957792de | overcloud-controller-0  | ACTIVE | ctlplane=192.168.255.15 | overcloud-full | control      |
| edc77778-8972-475e-a541-ff40eb944197 | overcloud-novacompute-1 | ACTIVE | ctlplane=192.168.255.26 | overcloud-full | compute      |
| 5448ce01-f05f-47ca-950a-ced14892c0d4 | overcloud-cephstorage-1 | ACTIVE | ctlplane=192.168.255.34 | overcloud-full | ceph-storage |
| ce6d862f-4bdf-4ba3-b711-7217915364d7 | overcloud-novacompute-0 | ACTIVE | ctlplane=192.168.255.19 | overcloud-full | compute      |
| e4507bd5-6f96-4b12-9cc0-6924709da59e | overcloud-cephstorage-0 | ACTIVE | ctlplane=192.168.255.44 | overcloud-full | ceph-storage |
+--------------------------------------+-------------------------+--------+-------------------------+----------------+--------------+
(undercloud) [stack@undercloud ~]$ 

(undercloud) [stack@undercloud ~]$ source overcloudrc 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack project list
+----------------------------------+---------+
| ID                               | Name    |
+----------------------------------+---------+
| 4eed7d0f06544625857d51cd77c5bd4c | admin   |
| ee1c68758bde41eaa9912c81dc67dad8 | service |
+----------------------------------+---------+
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ 
(overcloud) [stack@undercloud ~]$ openstack network agent list  
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| ID                                   | Agent Type         | Host                                | Availability Zone | Alive | State | Binary                    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
| 10495de9-ba4b-41fe-b30a-b90ec3f8728b | Open vSwitch agent | overcloud-novacompute-1.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| 1515ad4a-5972-46c3-af5f-e5446dff7ac7 | L3 agent           | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-l3-agent          |
| 322e62ca-1e5a-479e-9a96-4f26d09abdd7 | DHCP agent         | overcloud-controller-0.localdomain  | nova              | :-)   | UP    | neutron-dhcp-agent        |
| 9c1de2f9-bac5-400e-998d-4360f04fc533 | Open vSwitch agent | overcloud-novacompute-0.localdomain | None              | :-)   | UP    | neutron-openvswitch-agent |
| d99c5657-851e-4d3c-bef6-f1e3bb1acfb0 | Open vSwitch agent | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-openvswitch-agent |
| ff85fae6-5543-45fb-a301-19c57b62d836 | Metadata agent     | overcloud-controller-0.localdomain  | None              | :-)   | UP    | neutron-metadata-agent    |
+--------------------------------------+--------------------+-------------------------------------+-------------------+-------+-------+---------------------------+
(overcloud) [stack@undercloud ~]$

설치 작업에는 여전히 작은 터치가 필요합니다. 작업 중인 시스템이 다른 네트워크에 있기 때문에 컨트롤러에 경로를 추가하는 것입니다. 이렇게 하려면 heat-admin 계정 아래 control-1로 이동하여 경로를 등록하세요.

(undercloud) [stack@undercloud ~]$ ssh [email protected]         
Last login: Fri Aug 14 09:47:40 2020 from 192.168.255.1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ip route add 10.169.0.0/16 via 192.168.255.254

자, 이제 지평선으로 갈 수 있습니다. 모든 정보(주소, 로그인 및 비밀번호)는 /home/stack/overcloudrc 파일에 있습니다. 최종 다이어그램은 다음과 같습니다.

그건 그렇고, 우리 설치에서는 기계 주소가 DHCP를 통해 발급되었으며 보시다시피 "무작위로" 발급되었습니다. 필요한 경우 배포 중에 어떤 주소를 어떤 머신에 연결해야 하는지 템플릿에서 엄격하게 정의할 수 있습니다.

가상 머신 간의 트래픽 흐름은 어떻게 되나요?

이 기사에서는 트래픽 전달을 위한 세 가지 옵션을 살펴보겠습니다.

• 하나의 L2 네트워크에 있는 하나의 하이퍼바이저에 있는 두 대의 시스템
• 동일한 L2 네트워크의 서로 다른 하이퍼바이저에 있는 두 시스템
• 서로 다른 네트워크에 있는 두 컴퓨터(교차 네트워크 루팅)

유동 주소와 분산 라우팅을 사용하여 외부 네트워크를 통해 외부 세계에 액세스하는 경우는 다음 번에 고려하겠습니다. 지금은 내부 트래픽에 중점을 두겠습니다.

확인하기 위해 다음 다이어그램을 구성해 보겠습니다.

4개의 가상 머신을 만들었습니다. 하나의 L3 네트워크(net-2)에 1개, net-1 네트워크에 2개 더 있습니다.

(overcloud) [stack@undercloud ~]$ nova list --tenant 5e18ce8ec9594e00b155485f19895e6c             
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| ID                                   | Name | Tenant ID                        | Status | Task State | Power State | Networks        |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
| f53b37b5-2204-46cc-aef0-dba84bf970c0 | vm-1 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.85 |
| fc8b6722-0231-49b0-b2fa-041115bef34a | vm-2 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.88 |
| 3cd74455-b9b7-467a-abe3-bd6ff765c83c | vm-3 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-1=10.0.1.90 |
| 7e836338-6772-46b0-9950-f7f06dbe91a8 | vm-4 | 5e18ce8ec9594e00b155485f19895e6c | ACTIVE | -          | Running     | net-2=10.0.2.8  |
+--------------------------------------+------+----------------------------------+--------+------------+-------------+-----------------+
(overcloud) [stack@undercloud ~]$ 

생성된 머신이 어떤 하이퍼바이저에 있는지 살펴보겠습니다.

(overcloud) [stack@undercloud ~]$ nova show f53b37b5-2204-46cc-aef0-dba84bf970c0 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-1                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000001                                        |

(overcloud) [stack@undercloud ~]$ nova show fc8b6722-0231-49b0-b2fa-041115bef34a | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-2                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000002                                        |

(overcloud) [stack@undercloud ~]$ nova show 3cd74455-b9b7-467a-abe3-bd6ff765c83c | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-3                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-0.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000003                                        |

(overcloud) [stack@undercloud ~]$ nova show 7e836338-6772-46b0-9950-f7f06dbe91a8 | egrep "hypervisor_hostname|instance_name|hostname"
| OS-EXT-SRV-ATTR:hostname             | vm-4                                                     |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | overcloud-novacompute-1.localdomain                      |
| OS-EXT-SRV-ATTR:instance_name        | instance-00000004                                        |

(오버클라우드) [stack@undercloud ~]$
머신 vm-1 및 vm-3은 컴퓨팅-0에 있고 머신 vm-2 및 vm-4는 노드 컴퓨팅-1에 있습니다.

또한 지정된 네트워크 간의 라우팅을 활성화하기 위해 가상 라우터가 생성되었습니다.

(overcloud) [stack@undercloud ~]$ openstack router list  --project 5e18ce8ec9594e00b155485f19895e6c
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| ID                                   | Name     | Status | State | Distributed | HA    | Project                          |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
| 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | router-1 | ACTIVE | UP    | False       | False | 5e18ce8ec9594e00b155485f19895e6c |
+--------------------------------------+----------+--------+-------+-------------+-------+----------------------------------+
(overcloud) [stack@undercloud ~]$ 

라우터에는 네트워크의 게이트웨이 역할을 하는 두 개의 가상 포트가 있습니다.

(overcloud) [stack@undercloud ~]$ openstack router show 0a4d2420-4b9c-46bd-aec1-86a1ef299abe | grep interface
| interfaces_info         | [{"subnet_id": "2529ad1a-6b97-49cd-8515-cbdcbe5e3daa", "ip_address": "10.0.1.254", "port_id": "0c52b15f-8fcc-4801-bf52-7dacc72a5201"}, {"subnet_id": "335552dd-b35b-456b-9df0-5aac36a3ca13", "ip_address": "10.0.2.254", "port_id": "92fa49b5-5406-499f-ab8d-ddf28cc1a76c"}] |
(overcloud) [stack@undercloud ~]$ 

하지만 트래픽이 어떻게 흐르는지 살펴보기 전에 현재 제어 노드(네트워크 노드이기도 함)와 컴퓨팅 노드에 무엇이 있는지 살펴보겠습니다. 컴퓨팅 노드부터 시작해 보겠습니다.

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-vsctl show
[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:3 missed:3
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

현재 노드에는 br-int, br-tun, br-ex라는 세 개의 ovs 브리지가 있습니다. 우리가 볼 수 있듯이 그들 사이에는 일련의 인터페이스가 있습니다. 이해를 돕기 위해 이러한 모든 인터페이스를 다이어그램에 표시하고 어떤 일이 발생하는지 살펴보겠습니다.

VxLAN 터널이 발생하는 주소를 보면 하나의 터널이 Compute-1(192.168.255.26)로 올라가고 두 번째 터널이 Control-1(192.168.255.15)로 올라가는 것을 볼 수 있습니다. 하지만 가장 흥미로운 점은 br-ex에는 물리적 인터페이스가 없다는 점이며, 어떤 흐름이 구성되어 있는지 살펴보면 이 브리지는 현재 트래픽만 삭제할 수 있다는 것을 알 수 있습니다.

[heat-admin@overcloud-novacompute-0 ~]$ ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.19  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe6a:eabe  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:6a:ea:be  txqueuelen 1000  (Ethernet)
        RX packets 2909669  bytes 4608201000 (4.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1821057  bytes 349198520 (333.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-novacompute-0 ~]$ 

출력에서 볼 수 있듯이 주소는 가상 브리지 인터페이스가 아닌 물리적 포트에 직접 연결됩니다.

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-ofctl dump-flows br-ex
 cookie=0x9169eae8f7fe5bb2, duration=216686.864s, table=0, n_packets=303, n_bytes=26035, priority=2,in_port="phy-br-ex" actions=drop
 cookie=0x9169eae8f7fe5bb2, duration=216686.887s, table=0, n_packets=0, n_bytes=0, priority=0 actions=NORMAL
[heat-admin@overcloud-novacompute-0 ~]$ 

첫 번째 규칙에 따르면 phy-br-ex 포트에서 나온 모든 항목을 삭제해야 합니다.
실제로 현재 이 인터페이스(br-int가 있는 인터페이스)를 제외하고는 이 브리지로 트래픽이 들어오는 다른 곳이 없으며, 감소량으로 판단하면 BUM 트래픽은 이미 브리지로 유입되었습니다.

즉, 트래픽은 VxLAN 터널을 통해서만 이 노드에서 나갈 수 있으며 다른 어떤 것도 할 수 없습니다. 하지만 DVR을 켜면 상황이 달라지는데 이에 대해서는 다음에 다루겠습니다. 예를 들어 VLAN을 사용하여 네트워크 격리를 사용하는 경우 VLAN 3에 하나의 L0 인터페이스가 아니라 여러 인터페이스가 있습니다. 그러나 VxLAN 트래픽은 동일한 방식으로 노드를 떠나지만 일종의 전용 VLAN에 캡슐화됩니다.

컴퓨팅 노드를 정리했으니 제어 노드로 넘어가겠습니다.

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl dpif/show
system@ovs-system: hit:930491 missed:825
  br-ex:
    br-ex 65534/1: (internal)
    eth0 1/2: (system)
    phy-br-ex 2/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/3: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
  br-tun:
    br-tun 65534/4: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff13 3/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.19)
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$

실제로 모든 것이 동일하다고 말할 수 있지만 IP 주소는 더 이상 물리적 인터페이스가 아닌 가상 브리지에 있습니다. 이는 이 포트가 트래픽이 외부 세계로 나가는 포트이기 때문에 수행됩니다.

[heat-admin@overcloud-controller-0 ~]$ ifconfig br-ex
br-ex: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 192.168.255.15  netmask 255.255.255.0  broadcast 192.168.255.255
        inet6 fe80::5054:ff:fe20:a22f  prefixlen 64  scopeid 0x20<link>
        ether 52:54:00:20:a2:2f  txqueuelen 1000  (Ethernet)
        RX packets 803859  bytes 1732616116 (1.6 GiB)
        RX errors 0  dropped 63  overruns 0  frame 0
        TX packets 808475  bytes 121652156 (116.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-ex
 port  VLAN  MAC                Age
    3   100  28:c0:da:00:4d:d3   35
    1     0  28:c0:da:00:4d:d3   35
    1     0  52:54:00:98:e9:d6    0
LOCAL     0  52:54:00:20:a2:2f    0
    1     0  52:54:00:2c:08:9e    0
    3   100  52:54:00:20:a2:2f    0
    1     0  52:54:00:6a:ea:be    0
[heat-admin@overcloud-controller-0 ~]$ 

이 포트는 br-ex 브리지에 연결되어 있으며 VLAN 태그가 없기 때문에 이 포트는 모든 VLAN이 허용되는 트렁크 포트입니다. 이제 트래픽은 vlan-id 0에 표시된 대로 태그 없이 외부로 이동합니다. 위의 출력.

현재 다른 모든 것은 컴퓨팅 노드와 유사합니다. 동일한 브리지, 동일한 터널이 두 개의 컴퓨팅 노드로 연결됩니다.

이 기사에서는 스토리지 노드를 고려하지 않을 것이지만 이해를 위해서는 이러한 노드의 네트워크 부분이 불명예스러울 정도로 평범하다고 ​​말할 필요가 있습니다. 우리의 경우에는 IP 주소가 할당된 물리적 포트(eth0)가 하나만 있습니다. VxLAN 터널, 터널 브리지 등이 없습니다. 아무 의미도 없기 때문에 OV가 전혀 없습니다. 네트워크 격리를 사용할 때 이 노드에는 두 개의 인터페이스(물리적 포트, 본체 또는 두 개의 VLAN - 중요하지 않습니다. 원하는 것에 따라 다름)가 있습니다. 하나는 관리용이고 두 번째는 트래픽용(VM 디스크에 쓰기) , 디스크에서 읽기 등)

우리는 서비스가 없을 때 노드에 무엇이 있는지 알아냈습니다. 이제 4개의 가상 머신을 실행하고 위에 설명된 구성표가 어떻게 변경되는지 살펴보겠습니다. 포트, 가상 라우터 등이 있어야 합니다.

지금까지 우리 네트워크는 다음과 같습니다:

각 컴퓨터 노드에는 두 개의 가상 머신이 있습니다. Compute-0을 예로 사용하여 모든 것이 어떻게 포함되는지 살펴보겠습니다.

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh list 
 Id    Name                           State
----------------------------------------------------
 1     instance-00000001              running
 3     instance-00000003              running

[heat-admin@overcloud-novacompute-0 ~]$ 

머신에는 단 하나의 가상 인터페이스(tap95d96a75-a0)만 있습니다.

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

이 인터페이스는 Linux 브리지에서 찾습니다.

[heat-admin@overcloud-novacompute-0 ~]$ sudo brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242904c92a8       no
qbr5bd37136-47          8000.5e4e05841423       no              qvb5bd37136-47
                                                        tap5bd37136-47
qbr95d96a75-a0          8000.de076cb850f6       no              qvb95d96a75-a0
                                                        tap95d96a75-a0
[heat-admin@overcloud-novacompute-0 ~]$ 

출력에서 볼 수 있듯이 브리지에는 tap95d96a75-a0 및 qvb95d96a75-a0이라는 두 개의 인터페이스만 있습니다.

여기에서는 OpenStack의 가상 네트워크 장치 유형에 대해 조금 살펴볼 가치가 있습니다.
vtap - 인스턴스(VM)에 연결된 가상 인터페이스
qbr - Linux 브리지
qvb 및 qvo - Linux 브리지 및 Open vSwitch 브리지에 연결된 vEth 쌍
br-int, br-tun, br-vlan — 개방형 vSwitch 브리지
patch-, int-br-, phy-br- - 브리지를 연결하는 개방형 vSwitch 패치 인터페이스
qg, qr, ha, fg, sg - 가상 장치가 OVS에 연결하는 데 사용하는 개방형 vSwitch 포트

아시다시피, 브리지에 vEth 쌍인 qvb95d96a75-a0 포트가 있는 경우 논리적으로 qvo95d96a75-a0이라고 불리는 해당 포트가 어딘가에 있습니다. OVS에 어떤 포트가 있는지 살펴보겠습니다.

[heat-admin@overcloud-novacompute-0 ~]$ sudo sudo ovs-appctl dpif/show
system@ovs-system: hit:526 missed:91
  br-ex:
    br-ex 65534/1: (internal)
    phy-br-ex 1/none: (patch: peer=int-br-ex)
  br-int:
    br-int 65534/2: (internal)
    int-br-ex 1/none: (patch: peer=phy-br-ex)
    patch-tun 2/none: (patch: peer=patch-int)
    qvo5bd37136-47 6/6: (system)
    qvo95d96a75-a0 3/5: (system)
  br-tun:
    br-tun 65534/3: (internal)
    patch-int 1/none: (patch: peer=patch-tun)
    vxlan-c0a8ff0f 3/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.15)
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$ 

보시다시피 포트는 br-int에 있습니다. Br-int는 가상 머신 포트를 종료하는 스위치 역할을 합니다. qvo95d96a75-a0 외에도 qvo5bd37136-47 포트가 출력에 표시됩니다. 이는 두 번째 가상 머신에 대한 포트입니다. 결과적으로 다이어그램은 이제 다음과 같습니다.

세심한 독자가 즉시 관심을 가져야 할 질문입니다. 가상 머신 포트와 OVS 포트 사이의 Linux 브리지는 무엇입니까? 사실은 시스템을 보호하기 위해 iptables에 지나지 않는 보안 그룹이 사용된다는 것입니다. OVS는 iptables와 작동하지 않으므로 이 "목발"이 발명되었습니다. 그러나 이는 더 이상 사용되지 않고 있으며 새 릴리스에서는 conntrack으로 대체되고 있습니다.

즉, 궁극적으로 계획은 다음과 같습니다.

하나의 L2 네트워크에 있는 하나의 하이퍼바이저에 있는 두 대의 시스템

이 두 VM은 동일한 L2 네트워크 및 동일한 하이퍼바이저에 있으므로 두 시스템 모두 동일한 VLAN에 있으므로 둘 사이의 트래픽은 논리적으로 br-int를 통해 로컬로 흐릅니다.

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000003
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap5bd37136-47 bridge     qbr5bd37136-47 virtio      fa:16:3e:83:ad:a4

[heat-admin@overcloud-novacompute-0 ~]$ 
[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int 
 port  VLAN  MAC                Age
    6     1  fa:16:3e:83:ad:a4    0
    3     1  fa:16:3e:44:98:20    0
[heat-admin@overcloud-novacompute-0 ~]$ 

동일한 L2 네트워크의 서로 다른 하이퍼바이저에 있는 두 시스템

이제 동일한 L2 네트워크에 있지만 서로 다른 하이퍼바이저에 있는 두 시스템 간에 트래픽이 어떻게 이동하는지 살펴보겠습니다. 솔직히 말해서 크게 달라지는 것은 없습니다. 단지 하이퍼바이저 간의 트래픽이 vxlan 터널을 통과할 뿐입니다. 예를 살펴보겠습니다.

트래픽을 감시할 가상 머신의 주소:

[heat-admin@overcloud-novacompute-0 ~]$ sudo virsh domiflist instance-00000001
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap95d96a75-a0 bridge     qbr95d96a75-a0 virtio      fa:16:3e:44:98:20

[heat-admin@overcloud-novacompute-0 ~]$ 

[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000002
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tape7e23f1b-07 bridge     qbre7e23f1b-07 virtio      fa:16:3e:72:ad:53

[heat-admin@overcloud-novacompute-1 ~]$ 

Compute-0의 br-int에 있는 전달 테이블을 살펴봅니다.

[heat-admin@overcloud-novacompute-0 ~]$  sudo ovs-appctl fdb/show br-int | grep fa:16:3e:72:ad:53
    2     1  fa:16:3e:72:ad:53    1
[heat-admin@overcloud-novacompute-0 ~]

트래픽은 포트 2로 이동해야 합니다. 어떤 종류의 포트인지 살펴보겠습니다.

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$

이것이 patch-tun, 즉 br-tun의 인터페이스입니다. br-tun의 패키지에 어떤 일이 일어나는지 살펴보겠습니다.

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:72:ad:53
 cookie=0x8759a56536b67a8e, duration=1387.959s, table=20, n_packets=1460, n_bytes=138880, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:72:ad:53 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-novacompute-0 ~]$ 

패킷은 VxLAN에 패키지되어 포트 2로 전송됩니다. 포트 2가 어디로 연결되는지 살펴보겠습니다.

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-tun | grep addr   
 1(patch-int): addr:b2:d1:f8:21:96:66
 2(vxlan-c0a8ff1a): addr:be:64:1f:75:78:a7
 3(vxlan-c0a8ff0f): addr:76:6f:b9:3c:3f:1c
 LOCAL(br-tun): addr:a2:5b:6d:4f:94:47
[heat-admin@overcloud-novacompute-0 ~]$

이것은 Compute-1의 vxlan 터널입니다.

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl dpif/show | egrep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/4: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.19, remote_ip=192.168.255.26)
[heat-admin@overcloud-novacompute-0 ~]$

Compute-1으로 이동하여 패키지에서 다음에 무슨 일이 일어나는지 살펴보겠습니다.

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:44:98:20
    2     1  fa:16:3e:44:98:20    1
[heat-admin@overcloud-novacompute-1 ~]$ 

Mac은 Compute-1의 br-int 전달 테이블에 있으며 위 출력에서 ​​볼 수 있듯이 br-tun을 향한 포트인 포트 2를 통해 표시됩니다.

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr   
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46

그러면 Compute-1의 br-int에 대상 poppy가 있는 것을 볼 수 있습니다.

[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:72:ad:53
    3     1  fa:16:3e:72:ad:53    0
[heat-admin@overcloud-novacompute-1 ~]$ 

즉, 수신된 패킷은 포트 3으로 이동하며 그 뒤에는 이미 가상 머신 인스턴스-00000003이 있습니다.

가상 인프라 학습을 위해 OpenStack을 배포하는 것의 장점은 하이퍼바이저 간의 트래픽을 쉽게 캡처하고 이에 따라 무슨 일이 일어나고 있는지 확인할 수 있다는 것입니다. 이제 우리가 할 일은 vnet 포트에서 Compute-0 방향으로 tcpdump를 실행하는 것입니다.

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet3
tcpdump: listening on vnet3, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:39:04.583459 IP (tos 0x0, ttl 64, id 16868, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.39096 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 8012, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.1.88: ICMP echo request, id 5634, seq 16, length 64
04:39:04.584449 IP (tos 0x0, ttl 64, id 35181, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.speedtrace-disc > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 59124, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.1.88 > 10.0.1.85: ICMP echo reply, id 5634, seq 16, length 64
	
*****************omitted*******************

첫 번째 줄은 주소 10.0.1.85의 Patek이 주소 10.0.1.88(ICMP 트래픽)로 이동하고 vni 22를 사용하여 VxLAN 패킷으로 래핑되고 패킷이 호스트 192.168.255.19(compute-0)에서 호스트 192.168.255.26로 이동함을 보여줍니다. .1(컴퓨팅-XNUMX). VNI가 ovs에 지정된 것과 일치하는지 확인할 수 있습니다.

actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:2 줄로 돌아가겠습니다. 0x16은 16진수 체계의 vni입니다. 이 숫자를 10번째 시스템으로 변환해 보겠습니다.

16 = 6*16^0+1*16^1 = 6+16 = 22

즉, vni는 현실에 해당합니다.

두 번째 줄은 왕복 교통량을 보여줍니다. 설명할 필요가 없으며 모든 것이 명확합니다.

서로 다른 네트워크에 있는 두 시스템(네트워크 간 라우팅)

오늘의 마지막 사례는 가상 라우터를 사용하여 한 프로젝트 내의 네트워크 간 라우팅입니다. 우리는 DVR이 없는 경우를 고려하고 있으므로(다른 기사에서 살펴보겠습니다) 라우팅이 네트워크 노드에서 발생합니다. 우리의 경우 네트워크 노드는 별도의 엔터티에 배치되지 않고 제어 노드에 위치합니다.

먼저 라우팅이 작동하는지 살펴보겠습니다.

$ ping 10.0.2.8
PING 10.0.2.8 (10.0.2.8): 56 data bytes
64 bytes from 10.0.2.8: seq=0 ttl=63 time=7.727 ms
64 bytes from 10.0.2.8: seq=1 ttl=63 time=3.832 ms
^C
--- 10.0.2.8 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 3.832/5.779/7.727 ms

이 경우 패킷은 게이트웨이로 이동하여 그곳으로 라우팅되어야 하므로 게이트웨이의 poppy 주소를 찾아야 하며, 이를 위해 인스턴스의 ARP 테이블을 확인합니다.

$ arp
host-10-0-1-254.openstacklocal (10.0.1.254) at fa:16:3e:c4:64:70 [ether]  on eth0
host-10-0-1-1.openstacklocal (10.0.1.1) at fa:16:3e:e6:2c:5c [ether]  on eth0
host-10-0-1-90.openstacklocal (10.0.1.90) at fa:16:3e:83:ad:a4 [ether]  on eth0
host-10-0-1-88.openstacklocal (10.0.1.88) at fa:16:3e:72:ad:53 [ether]  on eth0

이제 대상(10.0.1.254) fa:16:3e:c4:64:70의 트래픽이 어디로 전송되어야 하는지 살펴보겠습니다.

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-appctl fdb/show br-int | egrep fa:16:3e:c4:64:70
    2     1  fa:16:3e:c4:64:70    0
[heat-admin@overcloud-novacompute-0 ~]$ 

포트 2가 어디로 연결되는지 살펴보겠습니다.

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:7e:7f:28:1f:bd:54
 2(patch-tun): addr:0a:bd:07:69:58:d9
 3(qvo95d96a75-a0): addr:ea:50:9a:3d:69:58
 6(qvo5bd37136-47): addr:9a:d1:03:50:3d:96
 LOCAL(br-int): addr:1a:0f:53:97:b1:49
[heat-admin@overcloud-novacompute-0 ~]$ 

모든 것이 논리적이며 트래픽은 br-tun으로 이동합니다. 어떤 vxlan 터널이 래핑될지 살펴보겠습니다.

[heat-admin@overcloud-novacompute-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:c4:64:70
 cookie=0x8759a56536b67a8e, duration=3514.566s, table=20, n_packets=3368, n_bytes=317072, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0001/0x0fff,dl_dst=fa:16:3e:c4:64:70 actions=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3
[heat-admin@overcloud-novacompute-0 ~]$ 

세 번째 포트는 vxlan 터널입니다.

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 

제어 노드를 살펴보겠습니다.

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

트래픽이 제어 노드에 도달했으므로 제어 노드로 이동하여 라우팅이 어떻게 발생하는지 확인해야 합니다.

기억하는 것처럼 내부의 제어 노드는 컴퓨팅 노드와 정확히 동일해 보였습니다. 동일한 브리지 XNUMX개가 있고, br-ex에만 노드가 외부로 트래픽을 보낼 수 있는 물리적 포트가 있었습니다. 인스턴스 생성으로 인해 컴퓨팅 노드의 구성이 변경되었습니다. Linux 브리지, iptables 및 인터페이스가 노드에 추가되었습니다. 네트워크 및 가상 라우터 생성도 제어 노드 구성에 표시를 남겼습니다.

따라서 게이트웨이 MAC 주소는 제어 노드의 br-int 전달 테이블에 있어야 합니다. 그것이 거기에 있고 어디에 있는지 확인해 봅시다:

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:c4:64:70
    5     1  fa:16:3e:c4:64:70    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$  sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

Mac은 포트 qr-0c52b15f-8f에서 볼 수 있습니다. OpenStack의 가상 포트 목록으로 돌아가면 이러한 유형의 포트는 다양한 가상 장치를 OVS에 연결하는 데 사용됩니다. 좀 더 정확하게 말하면 qr은 네임스페이스로 표현되는 가상 라우터에 대한 포트이다.

서버에 어떤 네임스페이스가 있는지 살펴보겠습니다.

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

최대 0개 사본. 하지만 이름으로 판단하면 각각의 목적을 짐작할 수 있습니다. 나중에 ID 1과 0의 인스턴스로 돌아가겠습니다. 이제 네임스페이스 qrouter-4a2420d4-9b46c-1bd-aec86-1a299efXNUMXabe에 관심이 있습니다.

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ip route
10.0.1.0/24 dev qr-0c52b15f-8f proto kernel scope link src 10.0.1.254 
10.0.2.0/24 dev qr-92fa49b5-54 proto kernel scope link src 10.0.2.254 
[heat-admin@overcloud-controller-0 ~]$ 

이 네임스페이스에는 이전에 만든 두 개의 내부 네임스페이스가 포함되어 있습니다. 두 가상 포트가 모두 br-int에 추가되었습니다. 대상 mac 주소로 판단되는 트래픽이 이 인터페이스로 이동했기 때문에 qr-0c52b15f-8f 포트의 mac 주소를 확인해 보겠습니다.

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe ifconfig qr-0c52b15f-8f
qr-0c52b15f-8f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.254  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fec4:6470  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:c4:64:70  txqueuelen 1000  (Ethernet)
        RX packets 5356  bytes 427305 (417.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5195  bytes 490603 (479.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[heat-admin@overcloud-controller-0 ~]$ 

즉, 이 경우 모든 것이 표준 라우팅 법칙에 따라 작동합니다. 트래픽은 호스트 10.0.2.8을 향하므로 두 번째 인터페이스 qr-92fa49b5-54를 통해 종료하고 vxlan 터널을 통해 컴퓨팅 노드로 이동해야 합니다.

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns exec qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe arp
Address                  HWtype  HWaddress           Flags Mask            Iface
10.0.1.88                ether   fa:16:3e:72:ad:53   C                     qr-0c52b15f-8f
10.0.1.90                ether   fa:16:3e:83:ad:a4   C                     qr-0c52b15f-8f
10.0.2.8                 ether   fa:16:3e:6c:ad:9c   C                     qr-92fa49b5-54
10.0.2.42                ether   fa:16:3e:f5:0b:29   C                     qr-92fa49b5-54
10.0.1.85                ether   fa:16:3e:44:98:20   C                     qr-0c52b15f-8f
[heat-admin@overcloud-controller-0 ~]$ 

모든 것이 논리적이며 놀랄 일이 아닙니다. 호스트 10.0.2.8의 poppy 주소가 br-int에서 표시되는 위치를 살펴보겠습니다.

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    2     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-int | grep addr
 1(int-br-ex): addr:2e:58:b6:db:d5:de
 2(patch-tun): addr:06:41:90:f0:9e:56
 3(tapca25a97e-64): addr:fa:16:3e:e6:2c:5c
 4(tap22015e46-0b): addr:fa:16:3e:76:c2:11
 5(qr-0c52b15f-8f): addr:fa:16:3e:c4:64:70
 6(qr-92fa49b5-54): addr:fa:16:3e:80:13:72
 LOCAL(br-int): addr:06:de:5d:ed:44:44
[heat-admin@overcloud-controller-0 ~]$ 

예상대로 트래픽은 br-tun으로 이동합니다. 트래픽이 다음으로 어느 터널로 이동하는지 살펴보겠습니다.

[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl dump-flows br-tun | grep fa:16:3e:6c:ad:9c
 cookie=0x2ab04bf27114410e, duration=5346.829s, table=20, n_packets=5248, n_bytes=498512, hard_timeout=300, idle_age=0, hard_age=0, priority=1,vlan_tci=0x0002/0x0fff,dl_dst=fa:16:3e:6c:ad:9c actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2
[heat-admin@overcloud-controller-0 ~]$
[heat-admin@overcloud-controller-0 ~]$ sudo ovs-ofctl show br-tun | grep addr
 1(patch-int): addr:a2:69:00:c5:fa:ba
 2(vxlan-c0a8ff1a): addr:86:f0:ce:d0:e8:ea
 3(vxlan-c0a8ff13): addr:72:aa:73:2c:2e:5b
 LOCAL(br-tun): addr:a6:cb:cd:72:1c:45
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 

트래픽은 컴퓨팅-1을 위한 터널로 들어갑니다. 글쎄, Compute-1에서는 모든 것이 간단합니다. br-tun에서 패키지는 br-int로 이동하고 거기에서 가상 머신 인터페이스로 이동합니다.

[heat-admin@overcloud-controller-0 ~]$ sudo sudo ovs-appctl dpif/show | grep vxlan-c0a8ff1a
    vxlan-c0a8ff1a 2/5: (vxlan: egress_pkt_mark=0, key=flow, local_ip=192.168.255.15, remote_ip=192.168.255.26)
[heat-admin@overcloud-controller-0 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-appctl fdb/show br-int | grep fa:16:3e:6c:ad:9c
    4     2  fa:16:3e:6c:ad:9c    1
[heat-admin@overcloud-novacompute-1 ~]$ sudo ovs-ofctl show br-int | grep addr                  
 1(int-br-ex): addr:8a:d7:f9:ad:8c:1d
 2(patch-tun): addr:46:cc:40:bd:20:da
 3(qvoe7e23f1b-07): addr:12:78:2e:34:6a:c7
 4(qvo3210e8ec-c0): addr:7a:5f:59:75:40:85
 LOCAL(br-int): addr:e2:27:b2:ed:14:46
[heat-admin@overcloud-novacompute-1 ~]$ 

이것이 실제로 올바른 인터페이스인지 확인해 보겠습니다.

[heat-admin@overcloud-novacompute-1 ~]$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.02429c001e1c       no
qbr3210e8ec-c0          8000.ea27f45358be       no              qvb3210e8ec-c0
                                                        tap3210e8ec-c0
qbre7e23f1b-07          8000.b26ac0eded8a       no              qvbe7e23f1b-07
                                                        tape7e23f1b-07
[heat-admin@overcloud-novacompute-1 ~]$ 
[heat-admin@overcloud-novacompute-1 ~]$ sudo virsh domiflist instance-00000004
Interface  Type       Source     Model       MAC
-------------------------------------------------------
tap3210e8ec-c0 bridge     qbr3210e8ec-c0 virtio      fa:16:3e:6c:ad:9c

[heat-admin@overcloud-novacompute-1 ~]$

사실 우리는 패키지 전체를 다 살펴봤습니다. 트래픽이 서로 다른 vxlan 터널을 통과하고 서로 다른 VNI로 종료되는 것을 확인하신 것 같습니다. 이것이 어떤 종류의 VNI인지 살펴보겠습니다. 그런 다음 노드의 제어 포트에서 덤프를 수집하고 트래픽이 위에 설명된 대로 정확하게 흐르는지 확인합니다.
따라서 Compute-0에 대한 터널에는 다음 작업=load:0->NXM_OF_VLAN_TCI[],load:0x16->NXM_NX_TUN_ID[],output:3이 있습니다. 0x16을 XNUMX진수 체계로 변환해 보겠습니다.

0x16 = 6*16^0+1*16^1 = 6+16 = 22

Compute-1에 대한 터널에는 VNI:actions=load:0->NXM_OF_VLAN_TCI[],load:0x63->NXM_NX_TUN_ID[],output:2가 있습니다. 0x63을 XNUMX진수 체계로 변환해 보겠습니다.

0x63 = 3*16^0+6*16^1 = 3+96 = 99

이제 덤프를 살펴보겠습니다.

[root@hp-gen9 bormoglotx]# tcpdump -vvv -i vnet4 
tcpdump: listening on vnet4, link-type EN10MB (Ethernet), capture size 262144 bytes

*****************omitted*******************

04:35:18.709949 IP (tos 0x0, ttl 64, id 48650, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.19.41591 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 64, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.710159 IP (tos 0x0, ttl 64, id 23360, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.26.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 63, id 49042, offset 0, flags [DF], proto ICMP (1), length 84)
    10.0.1.85 > 10.0.2.8: ICMP echo request, id 5378, seq 9, length 64
04:35:18.711292 IP (tos 0x0, ttl 64, id 43596, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.26.42588 > 192.168.255.15.4789: [no cksum] VXLAN, flags [I] (0x08), vni 99
IP (tos 0x0, ttl 64, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
04:35:18.711531 IP (tos 0x0, ttl 64, id 8555, offset 0, flags [DF], proto UDP (17), length 134)
    192.168.255.15.38983 > 192.168.255.19.4789: [no cksum] VXLAN, flags [I] (0x08), vni 22
IP (tos 0x0, ttl 63, id 55103, offset 0, flags [none], proto ICMP (1), length 84)
    10.0.2.8 > 10.0.1.85: ICMP echo reply, id 5378, seq 9, length 64
	
*****************omitted*******************

첫 번째 패킷은 vni 192.168.255.19를 사용하여 호스트 0(compute-192.168.255.15)에서 호스트 1(control-22)로의 vxlan 패킷이며, 내부에는 호스트 10.0.1.85에서 호스트 10.0.2.8로 ICMP 패킷이 패키징됩니다. 위에서 계산한 대로 vni는 출력에서 ​​본 것과 일치합니다.

두 번째 패킷은 vni 192.168.255.15를 사용하여 호스트 1(control-192.168.255.26)에서 호스트 1(compute-99)으로의 vxlan 패킷으로, 내부에는 호스트 10.0.1.85에서 호스트 10.0.2.8로 ICMP 패킷이 패키징됩니다. 위에서 계산한 대로 vni는 출력에서 ​​본 것과 일치합니다.

다음 두 패킷은 10.0.2.8가 아닌 10.0.1.85의 반환 트래픽입니다.

즉, 결국 우리는 다음과 같은 제어 노드 구성표를 얻었습니다.

그게 다인 것 같나요? 우리는 두 개의 네임스페이스를 잊어버렸습니다:

[heat-admin@overcloud-controller-0 ~]$ sudo  ip netns
qrouter-0a4d2420-4b9c-46bd-aec1-86a1ef299abe (id: 2)
qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 (id: 1)
qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 (id: 0)
[heat-admin@overcloud-controller-0 ~]$ 

클라우드 플랫폼의 아키텍처에 대해 이야기했듯이, 기계가 DHCP 서버로부터 자동으로 주소를 받으면 좋을 것입니다. 이는 두 네트워크 10.0.1.0/24 및 10.0.2.0/24에 대한 두 개의 DHCP 서버입니다.

이것이 사실인지 확인해 봅시다. 이 네임스페이스에는 DHCP 서버 자체의 주소인 10.0.1.1 주소 하나만 있으며 br-int에도 포함되어 있습니다.

[heat-admin@overcloud-controller-0 ~]$ sudo ip netns exec qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2 ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1  bytes 28 (28.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1  bytes 28 (28.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tapca25a97e-64: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1450
        inet 10.0.1.1  netmask 255.255.255.0  broadcast 10.0.1.255
        inet6 fe80::f816:3eff:fee6:2c5c  prefixlen 64  scopeid 0x20<link>
        ether fa:16:3e:e6:2c:5c  txqueuelen 1000  (Ethernet)
        RX packets 129  bytes 9372 (9.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 49  bytes 6154 (6.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

제어 노드의 이름에 qdhcp-67a3798c-32c0-4c18-8502-2531247e3cc2를 포함하는 프로세스가 있는지 살펴보겠습니다.

[heat-admin@overcloud-controller-0 ~]$ ps -aux | egrep qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 
root      640420  0.0  0.0   4220   348 ?        Ss   11:31   0:00 dumb-init --single-child -- ip netns exec qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638 /usr/sbin/dnsmasq -k --no-hosts --no-resolv --pid-file=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/pid --dhcp-hostsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/host --addn-hosts=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/addn_hosts --dhcp-optsfile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/opts --dhcp-leasefile=/var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases --dhcp-match=set:ipxe,175 --local-service --bind-dynamic --dhcp-range=set:subnet-335552dd-b35b-456b-9df0-5aac36a3ca13,10.0.2.0,static,255.255.255.0,86400s --dhcp-option-force=option:mtu,1450 --dhcp-lease-max=256 --conf-file= --domain=openstacklocal
heat-ad+  951620  0.0  0.0 112944   980 pts/0    S+   18:50   0:00 grep -E --color=auto qdhcp-7d541e74-1c36-4e1d-a7c4-0968c8dbc638
[heat-admin@overcloud-controller-0 ~]$ 

그러한 프로세스가 있으며 위 출력에 표시된 정보를 기반으로 예를 들어 현재 임대 가능한 항목을 확인할 수 있습니다.

[heat-admin@overcloud-controller-0 ~]$ cat /var/lib/neutron/dhcp/7d541e74-1c36-4e1d-a7c4-0968c8dbc638/leases
1597492111 fa:16:3e:6c:ad:9c 10.0.2.8 host-10-0-2-8 01:fa:16:3e:6c:ad:9c
1597491115 fa:16:3e:76:c2:11 10.0.2.1 host-10-0-2-1 *
[heat-admin@overcloud-controller-0 ~]$

결과적으로 우리는 제어 노드에서 다음과 같은 서비스 세트를 얻습니다.

글쎄요, 명심하세요. 이것은 단지 4개의 머신, 2개의 내부 네트워크 및 3개의 가상 라우터입니다... 지금 여기에는 외부 네트워크가 없습니다. 각각 자체 네트워크(겹침)가 있는 다양한 프로젝트가 있습니다. 분산 라우터가 꺼졌고 결국 테스트 벤치에는 제어 노드가 하나만 있었습니다(내결함성을 위해서는 300개의 노드로 구성된 쿼럼이 있어야 함). 상거래에서는 모든 것이 "약간" 더 복잡하다는 것이 논리적이지만, 이 간단한 예에서 우리는 그것이 어떻게 작동해야 하는지 이해합니다. 네임스페이스가 XNUMX개인지 XNUMX개인지는 물론 중요하지만 운영의 ​​관점에서는 전체 구조에서는 크게 변경되는 것이 없습니다. 일부 공급업체 SDN을 연결하지 않더라도 말이죠. 그러나 그것은 완전히 다른 이야기입니다.

흥미로웠기를 바랍니다. 의견/추가 사항이 있거나 제가 완전히 거짓말을 한 부분이 있는 경우(저는 인간이고 제 의견은 항상 주관적입니다) 수정/추가해야 할 사항을 적어주세요. 모든 내용을 수정/추가하겠습니다.

결론적으로 Openstack(바닐라 및 공급업체 모두)과 VMWare의 클라우드 솔루션을 비교하는 방법에 대해 몇 마디 말씀드리고 싶습니다. 지난 몇 년 동안 이 질문을 너무 자주 받았는데 솔직히 말하자면 이미 지쳤지만 여전히. 제 생각에는 이 두 솔루션을 비교하는 것이 매우 어렵지만 두 솔루션 모두에 단점이 있으며 하나의 솔루션을 선택할 때 장단점을 따져볼 필요가 있다는 점은 확실히 말할 수 있습니다.

OpenStack이 커뮤니티 중심 솔루션이라면 VMWare는 원하는 것(읽기 - 수익성이 있는 것)만 수행할 권리가 있으며 이는 논리적입니다. 왜냐하면 OpenStack은 고객으로부터 돈을 버는 데 익숙한 상업 회사이기 때문입니다. 그러나 한 가지 크고 중요한 문제가 있습니다. 예를 들어 Nokia에서 OpenStack을 벗어날 수 있고 약간의 비용으로 Juniper(Contrail Cloud)와 같은 솔루션으로 전환할 수 있지만 VMWare에서 벗어날 가능성은 거의 없습니다. . 나에게 이 두 가지 솔루션은 다음과 같습니다. Openstack(공급업체)은 사용자가 갇힌 간단한 케이지이지만 키가 있고 언제든지 떠날 수 있습니다. VMWare는 황금 케이지입니다. 소유자가 케이지 열쇠를 갖고 있으므로 비용이 많이 듭니다.

나는 첫 번째 제품이나 두 번째 제품을 홍보하는 것이 아닙니다. 필요한 것을 선택하십시오. 그러나 그러한 선택이 있었다면 IT 클라우드용 VMWare(낮은 부하, 손쉬운 관리), 일부 공급업체의 OpenStack(Nokia 및 Juniper는 매우 우수한 턴키 솔루션 제공), Telecom 클라우드용 두 가지 솔루션을 모두 선택할 것입니다. 저는 순수한 IT 목적으로 Openstack을 사용하지 않을 것입니다. 대포로 참새를 쏘는 것과 같지만 중복성 외에는 사용에 대한 금기 사항이 없습니다. 그러나 통신에서 VMWare를 사용하는 것은 포드 랩터(Ford Raptor)에서 쇄석을 운반하는 것과 같습니다. 겉보기에는 아름답지만 운전자는 한 번이 아닌 10번의 주행을 해야 합니다.

제 생각에는 VMWare의 가장 큰 단점은 완전한 폐쇄성입니다. 회사는 vSAN이나 하이퍼바이저 커널의 내용과 같이 작동 방식에 대한 정보를 제공하지 않습니다. 단순히 수익성이 없습니다. VMWare 전문가가 되지 마십시오. 공급업체의 지원이 없으면 운명이 정해져 있습니다. (저는 사소한 질문에 당황하는 VMWare 전문가를 자주 만납니다.) 나에게 VMWare는 후드가 잠긴 자동차를 구입합니다. 예, 타이밍 벨트를 교체할 수 있는 전문가가 있을 수 있지만 이 솔루션을 판매한 사람만이 후드를 열 수 있습니다. 개인적으로 저는 제가 적응할 수 없는 솔루션을 좋아하지 않습니다. 당신은 후드 아래로 들어갈 필요가 없다고 말할 것입니다. 예, 가능합니다. 하지만 20~30개의 가상 머신, 40~50개의 네트워크(그 중 절반은 외부로 나가고 싶어하고 나머지 절반은 요청함)로 구성된 대규모 기능을 클라우드에서 조립해야 할 때 살펴보겠습니다. SR-IOV 가속. 그렇지 않으면 이러한 자동차가 수십 대 더 필요합니다. 그렇지 않으면 성능이 충분하지 않습니다.

다른 관점도 있으므로 무엇을 선택할지는 오직 본인만이 결정할 수 있으며, 가장 중요한 것은 자신의 선택에 대한 책임은 본인에게 있다는 것입니다. 이것은 Nokia, Juniper, Red Hat, VMWare 등 최소 4개 제품을 보고 만져본 사람의 의견일 뿐입니다. 즉, 비교할 것이 있습니다.

출처 : habr.com