열린 성운. 짧은 메모

안녕하세요 여러분. 이 글은 가상화 플랫폼을 선택할 때 여전히 고민하고 있는 분들을 위해 작성되었으며, "Proxmox를 설치했고 모든 것이 훌륭합니다. 6년 동안 한 번도 중단 없이 가동되었습니다." 시리즈의 글을 읽은 분들을 위해 작성되었습니다. 하지만 하나 이상의 박스형 솔루션을 설치한 후에는 모니터링을 더 이해하기 쉽게 하기 위해 여기와 여기를 어떻게 조정하고, 백업을 제어하기 위해 여기와 여기를 어떻게 조정해야 할지 의문이 생깁니다. 그러다가 시간이 지나면서 좀 더 기능적인 것을 원한다는 걸 깨닫게 되고, 시스템 내부의 모든 것이 명확해야 하고, 이 블랙박스는 원하지 않거나, 하이퍼바이저와 여러 대의 가상 머신 외에 다른 것을 사용하고 싶어집니다. 이 글에서는 Opennebula 플랫폼을 기반으로 한 몇 가지 생각과 실습을 소개합니다. 제가 이 플랫폼을 선택한 이유는 이 플랫폼이 리소스를 많이 사용하지 않고 아키텍처가 그렇게 복잡하지 않기 때문입니다.

따라서 우리가 보는 바와 같이 많은 클라우드 공급업체가 KVM을 기반으로 작업하고 머신 관리를 위한 외부 바인딩을 만들고 있습니다. 대규모 호스팅 업체가 클라우드 인프라에 대한 자체 바인딩을 작성하는 것은 분명합니다. 예를 들어 YANDEX가 그렇습니다. 누군가가 openstack을 사용하여 이를 기반으로 바인딩을 만들었습니다 - SELECTEL, MAIL.RU. 하지만 자체 하드웨어와 소규모 전문가 인력이 있다면 일반적으로 기성품인 VM웨어, HYPER-V를 선택합니다. 무료 라이선스와 유료 라이선스가 있지만, 지금은 그런 것에 대한 이야기가 아닙니다. 열광적인 사람들에 대해 이야기해 보죠. 이들은 회사에서 "다음에 누가 이걸 서비스할 건가요?", "나중에 이걸 생산에 투입할까요? 무섭죠."라고 분명히 말했음에도 불구하고, 새로운 것을 제안하고 시도하는 것을 두려워하지 않는 사람들입니다. 하지만 이러한 솔루션을 먼저 테스트 환경에서 사용해 보고, 모두가 만족한다면 더욱 심각한 환경에서 추가 개발 및 사용 문제를 제기할 수 있습니다.

또한 보고서에 대한 링크는 다음과 같습니다. www.youtube.com/watch?v=47Mht_uoX3A 이 플랫폼 개발에 적극적으로 참여했습니다.

아마도 이 글에는 불필요하지만 숙련된 전문가에게는 이미 명확하게 이해되는 내용이 있을 수 있으며, 비슷한 명령어와 설명이 온라인에 이미 있기 때문에 모든 내용을 설명하지 않는 경우도 있을 것입니다. 이는 단지 제가 이 플랫폼을 사용하면서 겪은 경험일 뿐입니다. 적극적으로 참여하신 분들의 의견에 따라 개선할 점과 제가 저지른 실수를 추가해 주시기 바랍니다. 모든 활동은 서로 다른 특성을 지닌 3대의 PC로 구성된 홈 설정에서 이루어졌습니다. 또한 저는 의도적으로 이 소프트웨어가 어떻게 작동하는지, 어떻게 설치하는지 설명하지 않았습니다. 아니요, 행정적인 경험과 제가 겪은 문제에 대해서만 말씀드리겠습니다. 아마도 이것이 누군가의 선택에 도움이 될 수도 있을 겁니다.

그럼 시작해볼까요. 시스템 관리자로서 저는 다음과 같은 사항을 중요하게 생각합니다. 이러한 사항들이 없다면 이 솔루션을 사용하기 어려울 것입니다.

1. 설치의 반복성

Opennebula를 설치하는 방법에 대한 지침이 아주 많으므로 아무런 문제가 없을 겁니다. 버전이 올라갈수록 새로운 기능이 등장하는데, 이 기능들이 다른 버전으로 넘어갈 때 작동하지 않는 경우가 있습니다.

2. 모니터링

노드 자체, kvm, opennebula를 모니터링하겠습니다. 다행히도 이미 준비된 것이 있습니다. Linux 호스트를 모니터링하는 데에는 Zabbix나 노드 내보내기 도구 등 다양한 옵션이 있습니다. 선호하는 방법을 사용하면 되지만, 현재는 Zabbix를 통해 시스템 메트릭(측정 가능한 온도, 디스크 배열 일관성)을 모니터링하는 것으로 정의하고, Prometheus의 내보내기 도구를 통해 애플리케이션을 모니터링하는 것으로 정의합니다. 예를 들어, KVM 모니터링 프로젝트를 수행할 수 있습니다. github.com/zhangjianweibj/prometheus-libvirt-exporter.git systemd를 통해 실행을 설정하면 아주 잘 작동하고 KVM 메트릭을 표시하며 기성 대시보드도 있습니다. grafana.com/grafana/dashboards/12538.

예를 들어, 내 파일은 다음과 같습니다.

/etc/systemd/system/libvirtd_exporter.service
[Unit]
Description=Node Exporter

[Service]
User=node_exporter
ExecStart=/usr/sbin/prometheus-libvirt-exporter --web.listen-address=":9101"

[Install]
WantedBy=multi-user.target

따라서 우리는 1개의 내보내기 프로그램을 가지고 있고, opennebula 자체를 모니터링하기 위해 두 번째 내보내기 프로그램이 필요한데, 저는 이것을 사용했습니다. github.com/kvaps/opennebula-exporter/blob/master/opennebula_exporter

일반에 추가 가능 node_exporter 시스템을 모니터링하려면 다음을 수행하세요.

node_exporter 파일에서 시작 부분을 다음과 같이 변경합니다.

ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collector

mkdir -p /var/lib/opennebula_exporter 디렉토리를 생성합니다.

위에 제시된 bash 스크립트는 먼저 콘솔을 통해 작업을 확인하고, 필요한 내용이 표시되면(오류가 발생하면 xmlstarlet을 설치) /usr/local/bin/opennebula_exporter.sh에 복사합니다.

매 분마다 cron에 작업을 추가합니다.

*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)

지표가 나타나기 시작했고, Prometheus를 사용하여 지표를 수집하고 그래프를 작성하여 알림을 생성할 수 있습니다. Grafana를 사용하면 다음과 같은 간단한 대시보드를 그릴 수 있습니다.

(여기서 내가 CPU와 RAM을 과도하게 할당한 것을 볼 수 있습니다)

Zabbix를 좋아하고 사용하는 사람들을 위해 github.com/OpenNebula/addon-zabbix

그게 전부 모니터링에 관한 이야기이고, 가장 중요한 건 모니터링이 존재한다는 거예요. 물론, 가상 머신을 모니터링하고 청구서에 데이터를 업로드하기 위한 내장 도구를 추가로 사용할 수 있습니다. 이 부분에서는 각자의 비전이 있으므로 아직은 이에 대해 더 자세히 작업을 시작하지 않았습니다.

아직은 로깅을 본격적으로 시작하지 않았어요. 가장 간단한 옵션은 td-agent를 추가하여 정규 표현식을 사용하여 /var/lib/one 디렉토리를 구문 분석하는 것입니다. 예를 들어, sunstone.log 파일은 nginx 정규 표현식과 플랫폼에 대한 요청 기록을 보여주는 다른 파일에 적합합니다. 이것의 장점은 무엇일까요? 예를 들어, "오류, 오류"의 개수를 명확하게 추적하고 오류가 발생한 위치와 수준을 빠르게 추적할 수 있습니다.

3. 백업

또한 sep과 같은 유료 개선 프로젝트도 있습니다. wiki.sepsoftware.com/wiki/index.php/4_4_3_Tigon:OpenNebula_Backup. 여기서 이해해야 할 점은 단순히 머신 이미지를 백업하는 것이 이 경우에는 동일하지 않다는 것입니다. 가상 머신은 완전한 통합(네트워크 설정, VM 이름, 애플리케이션의 사용자 정의 설정을 설명하는 동일한 컨텍스트 파일)을 통해 작동해야 하기 때문입니다. 그러므로 여기서 우리는 무엇을 어떻게 백업할지 결정합니다. 어떤 경우에는 vm 자체에 있는 내용의 복사본을 만드는 것이 더 좋습니다. 그리고 아마도 이 머신에서 하나의 디스크만 백업하면 될 수도 있습니다.

예를 들어, 우리는 모든 머신이 영구 이미지로 시작된다는 것을 확인했으므로 다음을 읽었습니다. docs.opennebula.io/5.12/eration/vm_management/img_guide.html

따라서 먼저 VM에서 이미지를 언로드할 수 있습니다.

onevm disk-saveas 74 3 prom.qcow2
Image ID: 77

Смотрим, под каким именем он сохранился

oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
   
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.

나는 또한 그것을 네트워크의 광대함 속에서 발견했습니다 흥미로운 보고서 그리고 더 많은 것이 있습니다 그런 오픈소스 프로젝트하지만 qcow2에 대한 저장공간만 있습니다.

하지만 우리 모두 알다시피 조만간 증분 백업이 필요한 시점이 옵니다. 여기서는 상황이 더 복잡하고 경영진이 유료 솔루션에 비용을 할당하거나 다른 방법을 택해 여기서는 리소스를 잘라내고 애플리케이션 수준에서 백업을 하고 새로운 노드와 가상 머신을 추가하는 것에 불과하다는 것을 이해할 것입니다. 그렇습니다. 여기서는 클라우드를 순전히 애플리케이션 클러스터를 실행하고 다른 플랫폼에서 데이터베이스를 실행하거나 공급업체에서 기성품을 가져오는 경우에 한해 이를 말합니다.

4. 사용 용이성

이 섹션에서는 제가 겪은 문제에 대해 설명하겠습니다. 예를 들어, 우리가 알고 있듯이 이미지에는 지속적인 것이 있습니다. 이 이미지를 VM에 마운트하면 모든 데이터가 이 이미지에 기록됩니다. 비영구적일 경우, 이미지는 저장소에 복사되고 데이터는 원본 이미지에서 복사된 곳에 기록됩니다. 이것이 템플릿 템플릿이 작동하는 방식입니다. 저는 지속성을 지정하는 것을 잊어서 여러 번 문제를 일으켰고 200GB의 이미지가 복사되었습니다. 문제는 이 절차는 실행 취소가 불가능하다는 것입니다. 노드로 가서 현재 프로세스 "cp"를 종료해야 합니다.

가장 큰 단점 중 하나는 GUI를 사용해서는 작업을 실행 취소할 수 없다는 것입니다. 아니면, 취소하고 아무 일도 일어나지 않는지 확인한 후 다시 시작하고 취소하면 실제로 이미지를 복사하는 cp 프로세스가 이미 2개 있을 것입니다.

그러면 opennebula가 각각의 새로운 인스턴스에 새로운 ID를 부여하는 이유를 이해하게 될 것입니다. 예를 들어, 동일한 Proxmox에서 ID 101로 VM을 생성하고 삭제한 다음 다시 생성하여 ID를 101로 지정했습니다. opennebula에서는 이런 일이 발생하지 않습니다. 각각의 새로운 인스턴스는 새로운 ID로 생성되며 여기에는 고유한 논리가 있습니다. 예를 들어, 오래된 데이터를 지우거나 설치에 실패하는 것입니다.

저장에도 동일하게 적용됩니다. 이 플랫폼은 주로 중앙 집중식 저장을 목표로 합니다. 로컬로 사용할 수 있는 애드온이 있지만, 이 경우의 요점은 그게 아닙니다. 앞으로 누군가가 노드에서 로컬 스토리지를 어떻게 활용하고, 이를 프로덕션에서 성공적으로 활용하는지에 대한 기사를 쓸 것이라고 생각합니다.

5. 최대한의 단순성

물론, 당신이 더 멀리 나아갈수록 당신을 이해해 줄 사람은 점점 줄어들 것입니다.

제가 있는 환경에서는(NFS 저장소가 있는 3개의 노드) 모든 것이 잘 작동합니다. 하지만 정전에 대한 실험을 한다면, 예를 들어 스냅샷을 실행하고 노드의 전원을 끄면 스냅샷이 있다는 설정을 DB에 저장하지만 실제로는 스냅샷이 없습니다(물론, 이 동작에 대해 원래 SQL 데이터베이스에 기록했지만 작업 자체가 성공적이지 않았다는 것은 다들 알고 계실 겁니다). 스냅샷을 생성할 때 장점은 별도의 파일이 형성되고 "부모"가 있으므로 문제가 발생하거나 GUI를 통해 작동하지 않더라도 qcow2 파일을 가져와 별도로 복원할 수 있다는 것입니다. docs.opennebula.io/5.8/Operation/vm_management/vm_instances.html

불행히도 네트워크에서는 일이 그렇게 간단하지 않습니다. 글쎄요, 적어도 openstack보다 간단하죠. 저는 VLAN(802.1Q)만 사용했는데 잘 작동했어요. 하지만 템플릿 네트워크의 설정을 변경하면 해당 설정이 이미 작동 중인 컴퓨터에는 적용되지 않아요. 즉, 네트워크 카드를 제거했다가 추가한 후에야 새로운 설정이 적용됩니다.

아직도 openstack과 비교하고 싶다면 이렇게 말할 수 있습니다. opennebula에서는 데이터 저장, 네트워크, 리소스 관리에 어떤 기술을 사용해야 하는지에 대한 명확한 정의가 없습니다. 각 관리자는 자신에게 더 편리한 기술이 무엇인지 스스로 결정합니다.

6. 추가 플러그인 및 설치

결국, 우리가 아는 대로 클라우드 플랫폼은 KVM뿐만 아니라 VMware ESXi도 관리할 수 있습니다. 안타깝게도 Vcenter에 풀이 없습니다. 시도해 보신 분이 계시면 알려주세요.

다른 클라우드 공급자에 대한 지원이 명시되어 있습니다. docs.opennebula.io/5.12/advanced_comComponents/cloud_bursting/index.html
AWS, 애저.

Selectel에서 Vmware Cloud를 연결하려고도 했지만 아무것도 작동하지 않았습니다. 전반적으로 여러 가지 요인이 있고 호스팅 제공업체의 기술 지원팀에 문의하는 것도 의미가 없기 때문에 포기했습니다.

또한, 새로운 버전에는 파이어크래커가 추가되었습니다. 이는 도커를 통한 KVM 바인딩과 같은 마이크로 VM을 출시한 것으로, 하드웨어 에뮬레이션에 리소스를 사용할 필요가 없기 때문에 다양성, 보안성, 생산성 향상이 더욱 향상되었습니다. 저는 도커와 관련해서 추가적인 프로세스를 사용하지 않고 이 에뮬레이션을 사용할 때 점유된 소켓이 없다는 점에서만 이점을 봅니다. 즉, 로드 밸런서로 사용하는 것이 충분히 가능합니다(하지만 모든 테스트를 완전히 수행하기 전까지는 이에 대해 별도의 기사를 쓰는 것이 좋을 듯합니다).

7. 긍정적인 사용자 경험 및 디버깅 오류

저는 제가 이 작업에 대해 관찰한 바를 공유하고 싶었습니다. 위에서 몇 가지를 설명했지만, 더 자세히 쓰고 싶습니다. 사실, 처음에 이게 올바른 시스템이 아니고 여기 있는 모든 게 해킹이라고 생각하는 사람은 아마 나 혼자가 아닐 겁니다. 그들은 이걸 어떻게 사용하는 걸까요? 하지만 모든 것이 매우 논리적이라는 것을 깨닫게 됩니다. 물론, 모든 사람을 만족시킬 수는 없고 어떤 것들은 개선이 필요합니다.

예를 들어, 한 데이터 저장소에서 다른 데이터 저장소로 디스크 이미지를 복사하는 간단한 작업이 있습니다. 제 경우에는 nfs가 있는 노드가 2개 있고, 이미지를 보냅니다. 복사는 opennebula 프런트엔드를 통해 수행됩니다. 하지만 우리는 모두 데이터를 호스트 간에 직접 복사해야 한다는 사실에 익숙합니다. 같은 vmware, hyper-v에서는 이런 방식에 익숙하지만 여기서는 다릅니다. 접근 방식과 이념이 다르며, 버전 5.12에서는 "데이터 저장소로 마이그레이션" 버튼을 제거했습니다. 중앙 집중식 저장소가 의미되기 때문에 머신 자체만 전송되고 저장소는 전송되지 않습니다.

다음은 다양한 원인으로 발생하는 일반적인 오류입니다. "가상 머신 배포 오류: /var/lib/one//datastores/103/10/deployment.5에서 도메인을 만들 수 없습니다." 아래는 가장 먼저 확인해야 할 내용입니다.

• 사용자 oneadmin의 이미지 권리;
• 사용자 oneadmin이 libvirtd를 실행할 수 있는 권한
• 데이터 저장소가 올바르게 마운트되었나요? 노드 자체의 경로를 확인해 보세요. 뭔가 떨어졌을 수도 있습니다.
• 네트워크가 잘못 구성되었거나, 프런트엔드 네트워크 설정에서 br0이 VLAN의 기본 인터페이스로 설정되어 있고, 노드에서는 bridge0으로 설정되어 있습니다. 두 설정은 동일해야 합니다.

시스템 데이터 저장소는 VM에 대한 메타데이터를 저장합니다. 영구 이미지로 VM을 실행하는 경우 VM은 VM을 생성한 스토리지에서 원래 생성된 구성에 액세스할 수 있어야 합니다. 이는 매우 중요합니다. 따라서 VM을 다른 데이터 저장소로 전송할 때는 모든 것을 두 번 확인해야 합니다.

8. 문서, 커뮤니티. 추가 개발

그리고 나머지는 좋은 문서와 커뮤니티, 그리고 가장 중요한 것은 이 프로젝트가 미래에도 계속 살아있다는 것입니다.

여기에서는 일반적으로 모든 것이 꽤 잘 문서화되어 있으며, 심지어 공식 소스에서라도 설치하고 질문에 대한 답을 찾는 것이 문제가 되지 않습니다.

커뮤니티, 활동적. 귀하의 설비에 사용할 수 있는 다양한 기성 솔루션을 게시합니다.

현재 5.12 이후 회사의 일부 정책이 변경되었습니다. forum.opennebula.io/t/towards-a-stronger-opennebula-community/8506/14 이 프로젝트가 어떻게 전개되는지 보는 것은 흥미로울 것입니다. 처음에 저는 해당 솔루션을 사용하는 몇몇 공급업체와 해당 산업이 제공하는 서비스에 대해 구체적으로 설명했습니다. 물론, 무엇을 사용해야 할지에 대한 명확한 답변은 없습니다. 하지만 규모가 작은 조직의 경우, 소규모 프라이빗 클라우드를 운영하는 데 드는 비용이 생각보다 크지 않을 수 있습니다. 가장 중요한 것은 자신에게 무엇이 필요한지 정확히 아는 것입니다.

따라서 클라우드 시스템을 무엇을 선택하든 하나의 제품에만 머물러서는 안 됩니다. 시간이 있다면 다른 보다 개방적인 솔루션을 살펴보는 것도 좋습니다.

좋은 대화가 있습니다 t.me/오픈네뷸라 그들은 적극적으로 도움을 주며, 문제에 대한 해결책을 찾기 위해 Google로 보내지 않습니다. 우리와 함께 하세요.

출처 : habr.com