열린 성운. 짧은 메모

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

따라서 우리가 볼 수 있듯이 많은 클라우드 제공업체는 kvm에서 작업하고 시스템을 제어하기 위해 외부 연결을 만듭니다. 대규모 호스팅 업체가 예를 들어 동일한 YANDEX와 같이 클라우드 인프라를 위한 자체 프레임워크를 작성한다는 것은 분명합니다. 누군가는 openstack을 사용하고 이를 기반으로 연결합니다(SELECTEL, MAIL.RU). 그러나 자체 하드웨어와 소규모 전문가 직원이 있는 경우 일반적으로 기성품인 VMWARE, 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)

측정항목이 나타나기 시작하면 측정항목을 프로메테우스처럼 사용하여 그래프를 작성하고 알림을 보낼 수 있습니다. Grafana에서는 예를 들어 이러한 간단한 대시보드를 그릴 수 있습니다.

(여기서는 CPU, RAM을 오버커밋한 것이 분명합니다)

Zabbix를 사랑하고 사용하는 분들을 위해 github.com/OpenNebula/addon-zabbix

모니터링에 관한 한 가장 중요한 것은 모니터링이 존재한다는 것입니다. 물론 내장된 가상 머신 모니터링 도구를 사용하고 청구서에 데이터를 업로드할 수도 있습니다. 여기에서는 모든 사람이 자신만의 비전을 가지고 있으므로 아직 이에 대해 더 자세히 작업을 시작하지 않았습니다.

아직 실제로 로깅을 시작하지 않았습니다. 가장 간단한 옵션은 td-agent를 추가하여 정규식으로 /var/lib/one 디렉토리를 구문 분석하는 것입니다. 예를 들어, sunstone.log 파일은 nginx 정규 표현식 및 플랫폼 액세스 기록을 보여주는 기타 파일과 일치합니다. 이것의 장점은 무엇입니까? 예를 들어, "오류, 오류" 개수를 명시적으로 추적할 수 있고, 어디에서 어느 수준까지 오작동이 있는지 빠르게 추적할 수 있습니다.

3. 백업

유료로 완료된 프로젝트도 있습니다(예: XNUMX월) 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를 사용하여 작업을 취소할 수 없다는 것입니다. 또는 오히려 취소하고 아무 일도 일어나지 않는 것을 확인하고 다시 시작하고 취소하면 실제로 이미지를 복사하는 2cp 프로세스가 이미 있을 것입니다.

그런 다음 opennebula가 각 새 인스턴스에 새 ID를 부여하는 이유를 이해하게 됩니다. 예를 들어 동일한 proxmox에서 ID가 101인 VM을 생성하고 삭제한 다음 다시 생성하고 ID는 101입니다. opennebula에서는 이런 일이 발생하지 않습니다. 각각의 새 인스턴스는 새 ID로 생성되며 여기에는 고유한 논리가 있습니다(예: 오래된 데이터 지우기 또는 설치 실패).

스토리지도 마찬가지인데, 무엇보다도 이 플랫폼은 중앙 집중식 스토리지를 목표로 합니다. 로컬을 사용하기 위한 애드온이 있지만 이 경우에는 이에 대해 이야기하지 않습니다. 앞으로 누군가가 노드에서 로컬 스토리지를 사용하고 프로덕션에서 성공적으로 사용하는 방법에 대한 기사를 작성할 것이라고 생각합니다.

5. 최대의 단순성

물론, 당신이 더 멀리 갈수록 당신을 이해할 사람은 적어집니다.

내 스탠드 조건(nfs 스토리지가 있는 3개 노드)에서는 모든 것이 잘 작동합니다. 그러나 예를 들어 스냅샷을 실행하고 노드의 전원을 끄는 등 정전과 관련된 실험을 수행하면 스냅샷이 있다는 설정을 데이터베이스에 저장하지만 실제로는 스냅샷이 없습니다. 처음에는 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를 연결하려고 시도했지만 아무것도 작동하지 않았습니다. 일반적으로 여러 요인이 있기 때문에 차단되었으며 호스팅 공급자의 기술 지원에 서면으로 쓸 필요가 없습니다.

또한 이제 새 버전에는 폭죽이 포함되어 있습니다. 이는 docker를 대체하는 kvm 하네스 유형인 microvm의 출시로, 장비 에뮬레이션에 리소스를 낭비할 필요가 없기 때문에 훨씬 더 다양한 활용성, 보안 및 향상된 생산성을 제공합니다. Docker에 비해 제가 볼 수 있는 유일한 장점은 이 에뮬레이션을 사용할 때 추가 프로세스 수를 차지하지 않고 점유된 소켓이 없다는 것입니다. 이를 로드 밸런서로 사용하는 것이 가능합니다(그러나 모든 테스트를 완전히 실행할 때까지 이에 대해 별도의 기사를 작성하는 것이 가치가 있을 것입니다).

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

나는 작업에 대한 나의 관찰을 공유하고 싶었고, 위에서 그 중 일부를 설명했으며, 더 많이 쓰고 싶습니다. 실제로 처음에 이것이 올바른 시스템이 아니며 일반적으로 여기에 있는 모든 것이 버팀목이라고 생각하는 사람은 나 뿐만이 아닐 것입니다. 그들은 어떻게 이것을 사용합니까? 그러나 모든 것이 매우 논리적이라는 것을 이해하게 됩니다. 물론 모든 사람을 만족시킬 수는 없으며 일부 측면에서는 개선이 필요합니다.

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

다음은 다양한 이유가 있는 인기 있는 오류입니다. "가상 머신 배포 중 오류 발생: /var/lib/one//datastores/103/10/deployment.5에서 도메인을 생성할 수 없습니다." 가장 먼저 살펴봐야 할 사항은 다음과 같습니다.

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

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

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

그리고 나머지, 좋은 문서, 커뮤니티 그리고 가장 중요한 것은 프로젝트가 앞으로도 계속 유지된다는 것입니다.

일반적으로 모든 것이 잘 문서화되어 있으며 공식 소스를 사용하더라도 질문에 대한 답변을 설치하고 찾는 데 문제가 되지 않습니다.

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

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

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

좋은 채팅이 있습니다 t.me/opennebula 그들은 적극적으로 도움을 주며 Google에서 문제에 대한 해결책을 검색하도록 귀하에게 보내지 않습니다. 우리와 함께하세요.

출처 : habr.com