lae.proxmox

Instaluje i konfiguruje Proxmox Virtual Environment 6.x/7.x/8.x na serwerach Debian.

Ten skrypt (role) umożliwia wdrażanie i zarządzanie instalacjami PVE na pojedynczym węźle oraz klastrami PVE (3+ węzły) na Debianie Buster (10) i Bullseye (11). Możesz skonfigurować następujące elementy z pomocą tego skryptu:

• Definicje RBAC PVE (role, grupy, użytkownicy i listy kontroli dostępu)
• Definicje pamięci masowej PVE
• datacenter.cfg
• Certyfikaty HTTPS dla interfejsu webowego Proxmox (własne)
• Wybór repozytoriów PVE (np. pve-no-subscription lub pve-enterprise)
• Moduły Watchdog (IPMI i NMI) z odpowiednią konfiguracją pve-ha-manager
• Ustawienia modułu ZFS i powiadomienia e-mail ZED

Po włączeniu klastrowania, ten skrypt wykonuje (lub pozwala na) następujące czynności:

• Zapewnia, że wszystkie hosty mogą się ze sobą łączyć jako root przez SSH
• Inicjalizuje nowy klaster PVE (lub może dołączyć istniejący)
• Tworzy lub dodaje nowe węzły do klastra PVE
• Ustawia Ceph na klastrze PVE
• Tworzy i zarządza grupami wysokiej dostępności

Wsparcie / Wkład

W przypadku wsparcia lub jeśli chcesz przyczynić się do tego skryptu, ale potrzebujesz wskazówek, dołącz do tego serwera Discord: https://discord.gg/cjqr6Fg. Proszę zauważyć, że to jest tymczasowe zaproszenie, więc będziesz musiał poczekać, aż @lae przydzieli ci rolę, w przeciwnym razie Discord usunie cię z serwera po wylogowaniu.

Szybki początek

Głównym celem tego skryptu jest skonfigurowanie i zarządzanie klastrem Proxmox VE (zobacz przykładowy skrypt), jednak ten skrypt można wykorzystać do szybkiej instalacji pojedynczych serwerów Proxmox.

Zakładam, że masz już Zainstalowanego Ansible. Będziesz musiał użyć zewnętrznej maszyny do instalacji Proxmox (głównie z powodu ponownego uruchamiania w trakcie instalacji, chociaż mogę to zrobić nieco inaczej w tym przypadku później).

Skopiuj poniższy skrypt do pliku o nazwie install_proxmox.yml:

- hosts: all
  become: True
  roles:
    - role: geerlingguy.ntp
      vars:
        ntp_manage_config: true
        ntp_servers:
          - clock.sjc.he.net
          - clock.fmt.he.net
          - clock.nyc.he.net
    - role: lae.proxmox
      vars:
        - pve_group: all
        - pve_reboot_on_kernel_update: true

Zainstaluj ten skrypt oraz skrypt do konfigurowania NTP:

ansible-galaxy install lae.proxmox geerlingguy.ntp

Teraz możesz przeprowadzić instalację:

ansible-playbook install_proxmox.yml -i $SSH_HOST_FQDN, -u $SSH_USER

Jeśli Twój SSH_USER ma hasło sudo, przekaż flagę -K do powyższego polecenia. Jeśli również logujesz się do hosta za pomocą hasła zamiast autoryzacji kluczem publicznym, przekaż flagę -k (upewnij się, że masz zainstalowane sshpass). Możesz ustawić te zmienne przed uruchomieniem polecenia lub po prostu je zamienić. Zwróć uwagę, że przecinek jest ważny, ponieważ oczekiwany jest listy (w przeciwnym razie spróbuje znaleźć plik zawierający listę hostów).

Po zakończeniu powinieneś uzyskać dostęp do instancji Proxmox VE pod adresem https://$SSH_HOST_FQDN:8006.

Wdrożenie w pełni funkcjonalnego klastra PVE 8.x

Utwórz nowy katalog skryptu. Nazywamy nasz lab-cluster. Nasz skrypt w końcu będzie wyglądał tak, ale Twój nie musi zawierać wszystkich kroków:

lab-cluster/
├── files
│   └── pve01
│       ├── lab-node01.local.key
│       ├── lab-node01.local.pem
│       ├── lab-node02.local.key
│       ├── lab-node02.local.pem
│       ├── lab-node03.local.key
│       └── lab-node03.local.pem
├── group_vars
│   ├── all
│   └── pve01
├── inventory
├── roles
│   └── requirements.yml
├── site.yml
└── templates
    └── interfaces-pve01.j2

Pierwszą rzeczą, którą możesz zauważyć, jest to, że mamy wiele plików .key i .pem. To są klucze prywatne i certyfikaty SSL, które ten skrypt wykorzysta do skonfigurowania interfejsu webowego Proxmox na wszystkich węzłach. Nie są one konieczne, możesz także korzystać z certyfikatów podpisanych przez CA, które Proxmox ustawia wewnętrznie. Możesz zwykle użyć Ansible Vault, aby zaszyfrować klucze prywatne, np.:

ansible-vault encrypt files/pve01/*.key

To wymaga podania hasła Vault podczas uruchamiania skryptu.

Najpierw określmy naszych hostów klastra. W naszym pliku inventory może to wyglądać tak:

[pve01]
lab-node01.local
lab-node02.local
lab-node03.local

Możesz mieć wiele klastrów, więc dobrze jest mieć jedną grupę dla każdego klastra. Teraz określmy wymagania naszych ról w pliku roles/requirements.yml:

---
- src: geerlingguy.ntp
- src: lae.proxmox

Potrzebujemy roli NTP do skonfigurowania NTP, więc używamy roli Jeffa Geerlinga, żeby to zrobić. Nie będziesz jej potrzebować, jeśli masz już skonfigurowane NTP lub masz inną metodę konfiguracji NTP.

Teraz określmy kilka zmiennych grupowych. Najpierw utwórz plik group_vars/all, aby ustawić zmienne związane z NTP:

---
ntp_manage_config: true
ntp_servers:
  - lab-ntp01.local iburst
  - lab-ntp02.local iburst

Oczywiście, zamień te serwery NTP na te, które preferujesz.

Teraz dla sedna naszego skryptu, zmienne grupowe dla pve01. Utwórz plik group_vars/pve01, dodaj poniższe i zmodyfikuj zgodnie ze swoimi potrzebami.

---
pve_group: pve01
pve_watchdog: ipmi
pve_ssl_private_key: "{{ lookup('file', pve_group + '/' + inventory_hostname + '.key') }}"
pve_ssl_certificate: "{{ lookup('file', pve_group + '/' + inventory_hostname + '.pem') }}"
pve_cluster_enabled: yes
pve_groups:
  - name: ops
    comment: Zespół operacyjny
pve_users:
  - name: admin1@pam
    email: [email protected]
    firstname: Admin
    lastname: Użytkownik 1
    groups: [ "ops" ]
  - name: admin2@pam
    email: [email protected]
    firstname: Admin
    lastname: Użytkownik 2
    groups: [ "ops" ]
pve_acls:
  - path: /
    roles: [ "Administrator" ]
    groups: [ "ops" ]
pve_storages:
  - name: localdir
    type: dir
    content: [ "images", "iso", "backup" ]
    path: /plop
    maxfiles: 4
pve_ssh_port: 22

interfaces_template: "interfaces-{{ pve_group }}.j2"

pve_group jest ustawione na nazwę grupy naszego klastra, pve01 - będzie używane do zabezpieczenia, że wszystkie hosty w tej grupie mogą się ze sobą łączyć i są zgrupowane. Zauważ, że nazwa klastra PVE również będzie ustawiona na tę nazwę grupy, chyba że określono inaczej w pve_cluster_clustername. Pozostawienie tej opcji niezdefiniowanej domyślnie ustawi nazwę klastra na proxmox.

pve_watchdog umożliwia wsparcie dla watchdog IPMI i konfiguruje menedżera HA PVE, aby go wykorzystać. Pozostaw niezdefiniowaną, jeśli nie chcesz tego konfigurować.

pve_ssl_private_key oraz pve_ssl_certificate wskazują na certyfikaty SSL dla klastra pve. Tutaj używane jest wyszukiwanie pliku, aby odczytać zawartość pliku w skrypcie, np. files/pve01/lab-node01.key. Możesz zamiast tego użyć zmiennych hosta, jeśli preferujesz.

pve_cluster_enabled włącza skrypt do wykonywania wszystkich zadań związanych z zarządzaniem klastrem. Obejmuje to tworzenie klastra, jeśli nie istnieje, lub dodawanie węzłów do istniejącego klastra. Są prowadzone sprawdzenia, aby upewnić się, że nie mieszają się węzły, które są już w istniejących klastrach o różnych nazwach.

pve_groups, pve_users, i pve_acls autoryzują niektórych lokalnych użytkowników UNIX (muszą już istnieć) do uzyskania dostępu do PVE i przyznają im rolę Administratora w składzie ops. Przeczytaj sekcję Zarządzanie użytkownikami i ACL po więcej informacji.

pve_storages pozwala na tworzenie różnych typów pamięci masowej i ich konfigurowanie. Backend musi być wspierany przez Proxmox. Przeczytaj sekcję Zarządzanie pamięcią masową po więcej informacji.

pve_ssh_port pozwala na zmianę portu SSH. Jeśli Twój SSH nasłuchuje na porcie innym niż domyślny 22, powinieneś ustawić tę zmienną. Jeśli nowy węzeł dołącza do klastra, klaster PVE musi komunikować się raz przez SSH.

pve_manage_ssh (domyślnie true) pozwala na wyłączenie wszystkich zmian, które ten moduł mógłby wprowadzić do konfiguracji serwera SSH. Jest to przydatne, jeśli używasz innego skryptu do zarządzania swoim serwerem SSH. Zauważ, że ustawienie tego na false nie jest oficjalnie wspierane, jesteś odpowiedzialny za odtworzenie zmian normalnie dokonywanych w ssh_cluster_config.yml i pve_add_node.yml.

interfaces_template jest ustawione na ścieżkę do szablonu, którego użyjemy do konfigurowania sieci na tych maszynach Debian. Jest to konieczne tylko, jeśli chcesz zarządzać siecią z Ansible, a nie ręcznie lub za pomocą każdego hosta w PVE. Powinieneś być zaznajomiony z Ansible przed zrobieniem tego, ponieważ Twoja metoda może polegać na ustawieniu zmiennych hosta dla adresów IP każdego hosta itd.

Zróbmy ten szablon interfejsu. Możesz spokojnie pominąć ten plik (i pozostawić go niezdefiniowanym w group_vars/pve01), w przeciwnym razie. Oto jeden, którego używam:

# {{ ansible_managed }}
auto lo
iface lo inet loopback

allow-hotplug enp2s0f0
iface enp2s0f0 inet manual

auto vmbr0
iface vmbr0 inet static
    address {{ lookup('dig', ansible_fqdn) }}
    gateway 10.4.0.1
    netmask 255.255.255.0
    bridge_ports enp2s0f0
    bridge_stp off
    bridge_fd 0

allow-hotplug enp2s0f1
auto enp2s0f1
iface enp2s0f1 inet static
    address {{ lookup('dig', ansible_hostname + "-clusternet.local") }}
    netmask 255.255.255.0

Możesz nie być zaznajomiony z wyszukiwaniem dig, ale zasadniczo tutaj wykonujemy zapytanie A dla każdej maszyny (np. lab-node01.local) dla pierwszego interfejsu (i konfiguruje go jako mostek, którego użyjemy dla interfejsów VM), a następnie kolejne lekko zmodyfikowane wyszukiwanie dla "sieci klastra", którą możemy używać dla Ceph ("lab-node01-clusternet.local"). Oczywiście, Twój może wyglądać zupełnie inaczej, zwłaszcza jeśli używasz łączenia, trzech różnych sieci do zarządzania/corosync, przechowywania i ruchu VM itd.

Na koniec napiszmy nasz skrypt. site.yml będzie wyglądał mniej więcej tak:

---
- hosts: all
  become: True
  roles:
    - geerlingguy.ntp

# Pomijaj to, jeśli nie modyfikujesz sieci przez Ansible
- hosts: pve01
  become: True
  serial: 1
  tasks:
    - name: Zainstaluj bridge-utils
      apt:
        name: bridge-utils

    - name: Skonfiguruj /etc/network/interfaces
      template:
        src: "{{ interfaces_template }}"
        dest: /etc/network/interfaces
      register: _configure_interfaces

    - block:
      - name: Reboot for networking changes
        shell: "sleep 5 && shutdown -r now 'Networking changes found, rebooting'"
        async: 1
        poll: 0

      - name: Wait for server to come back online
        wait_for_connection:
          delay: 15
      when: _configure_interfaces is changed

- hosts: pve01
  become: True
  roles:
    - lae.proxmox

Zasadniczo uruchamiamy rolę NTP na wszystkich hostach (możesz chcieć dodać kilka maszyn niebędących Proxmox), konfigurujemy sieć na pve01 z naszą oddzielną siecią klastra i układem mostków, uruchamiamy ponownie, aby te zmiany miały moc, a następnie uruchamiamy ten skrypt Proxmox przeciwko hostom, aby skonfigurować klaster.

W tym momencie, nasz skrypt jest gotowy i możemy go uruchomić.

Upewnij się, że role i zależności są zainstalowane:

ansible-galaxy install -r roles/requirements.yml --force
pip install jmespath dnspython

jmespath jest wymagana dla niektórych zadań związanych z klastrowaniem. dnspython jest wymagany tylko jeśli używasz wyszukiwania dig, którego prawdopodobnie nie użyjesz, jeśli pominąłeś konfigurowanie sieci. Przekazujemy --force do ansible-galaxy, aby zaktualizować role do ich najnowszych wersji, jeśli są już zainstalowane.

Uruchom teraz skrypt:

ansible-playbook -i inventory site.yml -e '{"pve_reboot_on_kernel_update": true}'

-e '{"pve_reboot_on_kernel_update": true}' zazwyczaj należy uruchomić za pierwszym razem podczas konfiguracji klastra Proxmox, ponieważ ponownie uruchomi serwer, aby uruchomić się w kernelu PVE. Kolejne uruchomienia powinny to pominąć, ponieważ chcesz sekwencyjnie ponownie uruchomić serwery po uruchomieniu klastra.

Aby określić konkretnego użytkownika, użyj -u root (zastępując root), a jeśli musisz podać hasła, użyj -k dla hasła SSH i/lub -K dla hasła sudo. Na przykład:

ansible-playbook -i inventory site.yml -K -u admin1

To poprosi o hasło sudo, a następnie zaloguje się jako użytkownik admin1 (używając autoryzacji klucza publicznego - dodaj -k dla hasła) i uruchomi playbooka.

To wszystko! Teraz powinieneś mieć w pełni wdrożony klaster Proxmox. Możesz chcieć stworzyć pamięć masową Ceph po tym (patrz Ceph po więcej informacji) i ewentualnie inne zadania, ale najtrudniejsza część jest już zakończona.

Przykładowy Skrypt

Ten skrypt skonfiguruje hosty w grupie pve01 jako jeden klaster oraz ponownie uruchomi maszyny, jeśli kernel był zaktualizowany. (Zaleca się ustawienie tej flagi tylko podczas instalacji - ponowne uruchomienia podczas pracy powinny odbywać się sekwencyjnie w czasie konserwacji.) Umożliwi również włączenie watchdog IPMI.

- hosts: pve01
  become: True
  roles:
    - role: geerlingguy.ntp
        ntp_manage_config: true
        ntp_servers:
          - clock.sjc.he.net,
          - clock.fmt.he.net,
          - clock.nyc.he.net
    - role: lae.proxmox
        pve_group: pve01
        pve_cluster_enabled: yes
        pve_reboot_on_kernel_update: true
        pve_watchdog: ipmi

Zmienne Roli

[variable]: [default] #[description/purpose]
pve_group: proxmox # grupa hostów, która zawiera hosty Proxmox do zgrupowania
pve_repository_line: "deb http://download.proxmox.com/debian/pve bullseye pve-no-subscription" # konfiguracja repozytoriów apt - zmień na enterprise jeśli potrzebujesz (chociaż TODO, mogą być potrzebne dalsze konfiguracje)
pve_remove_subscription_warning: true # naprawia komunikaty o ostrzeżeniu subskrypcyjnym w proxmox, jeśli używasz edycji społecznościowej
pve_extra_packages: [] # wszelkie dodatkowe pakiety, które możesz chcieć zainstalować, np. ngrep
pve_run_system_upgrades: false # zezwól roli na przeprowadzanie aktualizacji systemowych
pve_run_proxmox_upgrades: true # zezwól roli na przeprowadzanie aktualizacji Proxmox VE
pve_check_for_kernel_update: true # uruchamia skrypt na hoście, aby sprawdzić wersje kernela
pve_reboot_on_kernel_update: false # jeśli ustawione na true, automatycznie ponownie uruchomi maszynę na aktualizacjach kernela
pve_reboot_on_kernel_update_delay: 60 # Liczba sekund, aby poczekać przed i po procesie ponownego uruchamiania, aby przejść do następnego zadania w trybie klastra
pve_remove_old_kernels: true # Obecnie usuwa kernel z głównego repozytorium Debiana
pve_pcie_passthrough_enabled: false # Ustaw to na true, aby włączyć PCIe passthrough.
pve_iommu_passthrough_mode: false # Ustaw to na true, aby umożliwić VM-om pomijanie tłumaczenia DMA. Może to zwiększyć wydajność w przypadku przekazywania IOMMU.
pve_iommu_unsafe_interrupts: false # Ustaw to na true, jeśli Twój system nie obsługuje mapowania przerwań.
pve_mediated_devices_enabled: false # Ustaw to na true, jeśli Twoje urządzenie obsługuje GVT-g i chcesz włączyć funkcjonalność podziału.
pve_pcie_ovmf_enabled: false # Ustaw to na true, aby włączyć GPU OVMF PCI passthrough.
pve_pci_device_ids: [] # Lista identyfikatorów urządzeń pci (patrz https://pve.proxmox.com/wiki/Pci_passthrough#GPU_Passthrough).
pve_vfio_blacklist_drivers: [] # Lista sterowników urządzeń do zablokowania na hoście Proxmox (patrz https://pve.proxmox.com/wiki/PCI(e)_Passthrough).
pve_pcie_ignore_msrs: false # Ustaw to na true, jeśli przekazujesz do maszyny z systemem Windows, aby zapobiec awarii VM.
pve_pcie_report_msrs: true # Ustaw to na false, aby zapobiec dziennikowi systemu dmesg nagłych awarii msrs.
pve_watchdog: none # Ustaw to na "ipmi", jeśli chcesz skonfigurować sprzętowy watchdog. Proxmox używa domyślnie watchdog'a oprogramowania (nmi_watchdog).
pve_watchdog_ipmi_action: power_cycle # Może być jednym z "reset", "power_cycle" lub "power_off".
pve_watchdog_ipmi_timeout: 10 # Liczba sekund, na które watchdog powinien czekać
pve_zfs_enabled: no # Określa, czy zainstalować i skonfigurować pakiety ZFS
# pve_zfs_options: "" # parametry modprobe do przekazania do modułu zfs przy uruchamianiu/modprobe
# pve_zfs_zed_email: "" # Powinno być ustawione na e-mail, aby otrzymywać powiadomienia ZFS
pve_zfs_create_volumes: [] # Lista wolumenów ZFS do utworzenia (do wykorzystania jako pamięć masowa PVE). Zobacz sekcję o zarządzaniu pamięcią.
pve_ceph_enabled: false # Określa, czy zainstalować i skonfigurować pakiety Ceph. Zobacz poniżej przykładową konfigurację.
pve_ceph_repository_line: "deb http://download.proxmox.com/debian/ceph-pacific bullseye main" # konfiguracja repozytoriów apt. Zostanie automatycznie ustawiona dla 6.x i 7.x (Dalsze informacje: https://pve.proxmox.com/wiki/Package_Repositories)
pve_ceph_network: "{{ (ansible_default_ipv4.network +'/'+ ansible_default_ipv4.netmask) | ansible.utils.ipaddr('net') }}" # Publiczna sieć Ceph
# pve_ceph_cluster_network: "" # Opcjonalny, jeśli sieć klastra ceph różni się od publicznej sieci (patrz https://pve.proxmox.com/pve-docs/chapter-pveceph.html#pve_ceph_install_wizard)
pve_ceph_nodes: "{{ pve_group }}" # Grupa hostów zawierająca wszystkie węzły Ceph
pve_ceph_mon_group: "{{ pve_group }}" # Grupa hostów zawierająca wszystkie hosty monitorujące Ceph
pve_ceph_mgr_group: "{{ pve_ceph_mon_group }}" # Grupa hostów zawierająca wszystkie menedżery Ceph
pve_ceph_mds_group: "{{ pve_group }}" # Grupa hostów zawierająca wszystkie hosty serwera metadanych Ceph
pve_ceph_osds: [] # Lista dysków OSD
pve_ceph_pools: [] # Lista pul do utworzenia
pve_ceph_fs: [] # Lista systemów plików CephFS do utworzenia
pve_ceph_crush_rules: [] # Lista reguł CRUSH do utworzenia
# pve_ssl_private_key: "" # Powinno być ustawione na zawartość klucza prywatnego do użycia do HTTPS
# pve_ssl_certificate: "" # Powinno być ustawione na zawartość certyfikatu do użycia do HTTPS
pve_roles: [] # Dodaj więcej ról o określonych uprawnieniach. Zobacz sekcję o zarządzaniu użytkownikami.
pve_groups: [] # Lista definicji grup do zarządzania w PVE. Zobacz sekcję o zarządzaniu użytkownikami.
pve_users: [] # Lista definicji użytkowników do zarządzania w PVE. Zobacz sekcję o zarządzaniu użytkownikami.
pve_storages: [] # Lista pamięci masowej do zarządzania w PVE. Zobacz sekcję o zarządzaniu pamięcią masową.
pve_datacenter_cfg: {} # Słownik do skonfigurowania pliku konfiguracyjnego PVE datacenter.cfg.
pve_domains_cfg: [] # Lista domen do użycia jako źródła uwierzytelniania w pliku konfiguracyjnym PVE domains.cfg.
pve_no_log: false # Ustaw to na true w produkcji, aby zapobiec ujawnianiu danych logowania do pamięci masowej w dziennikach uruchomieniowych. (może być używane w innych zadaniach w przyszłości)

Aby włączyć klastrowanie za pomocą tego skryptu, skonfiguruj odpowiednio następujące zmienne:

pve_cluster_enabled: no # Ustaw to na yes, aby skonfigurować hosty do zgrupowania razem
pve_cluster_clustername: "{{ pve_group }}" # Powinno być ustawione na nazwę klastra PVE
pve_manage_hosts_enabled : yes # Ustaw to na no, aby NIE konfigurować pliku hostów (w przypadku używania vpn i plik hostów jest już skonfigurowany)

Poniższe zmienne są używane do dostarczania informacji o sieci do corosync. Są znane jako ring0_addr/ring1_addr lub link0_addr/link1_addr, w zależności od wersji PVE. Powinny być adresami IPv4 lub IPv6. Możesz również skonfigurować priorytet tych interfejsów, aby wskazać corosync, który interfejs powinien obsługiwać ruch klastra (niższe numery oznaczają wyższy priorytet). Aby uzyskać więcej informacji, zobacz rozdział Cluster Manager w dokumentacji PVE.

# pve_cluster_addr0: "{{ domyślnie interfejs ipv4 lub ipv6, jeśli wykryty }}"
# pve_cluster_addr1: "adres IP innego interfejsu lub nazwa hosta"
# pve_cluster_addr0_priority: 255
# pve_cluster_addr1_priority: 0

Możesz ustawić opcje w pliku konfiguracyjnym datacenter.cfg:

pve_datacenter_cfg:
  keyboard: en-us

Możesz również skonfigurować grupy menedżera HA:

pve_cluster_ha_groups: [] # Lista grup HA do utworzenia w PVE.

Ten przykład tworzy grupę "lab_node01" dla zasobów przydzielonych do hosta lab-node01:

pve_cluster_ha_groups:
  - name: lab_node01
    comment: "Moja grupa HA"
    nodes: "lab-node01"
    nofailback: 0
    restricted: 0

Wszystkie opcje konfiguracyjne wspierane w pliku datacenter.cfg są opisane w podręczniku Proxmox w sekcji datacenter.cfg.

Aby automatycznie ładować sieci na żywo przez interfejs webowy PVE, musisz zainstalować pakiet ifupdown2. Zauważ, że to usunie ifupdown. Możesz to określić za pomocą zmiennej roli pve_extra_packages.

Możesz ustawić domeny jako źródła uwierzytelniania w pliku konfiguracyjnym domains.cfg. Jeśli ten plik nie jest obecny, dostępne są tylko domeny Linux PAM oraz serwer uwierzytelniania Proxmox VE. Obsługiwane typy to pam, pve, ad i ldap. Możliwe jest automatyczne synchronizowanie użytkowników i grup dla domen opartych na LDAP (LDAP i Microsoft Active Directory) z sync: true. Jedna z domen powinna mieć właściwość default: 1, aby oznaczyć ją jako domyślną:

pve_domains_cfg:
  - name: pam
    type: pam
    attributes:
      comment: Uwierzytelnianie standardowe Linux PAM
  - name: pve
    type: pve
    attributes:
      comment: Serwer uwierzytelniania Proxmox VE
  - name: ad
    type: ad
    attributes:
      comment: Uwierzytelnianie Active Directory
      domain: yourdomain.com
      server1: dc01.yourdomain.com
      default: 1
      secure: 1
      server2: dc02.yourdomain.com
  - name: ldap
    type: ldap
    sync: true
    attributes:
      comment: Uwierzytelnianie LDAP
      base_dn: CN=Users,dc=yourdomain,dc=com
      bind_dn: "uid=svc-reader,CN=Users,dc=yourdomain,dc=com"
      bind_password: "{{ secret_ldap_svc_reader_password }}"
      server1: ldap1.yourdomain.com
      user_attr: uid
      secure: 1
      server2: ldap2.yourdomain.com

Zależności

Ten skrypt nie instaluje NTP, więc powinieneś sam skonfigurować NTP, np. za pomocą roli geerlingguy.ntp, jak pokazano w przykładowym skrypcie.

Kiedy klastrowanie jest włączone, ten skrypt korzysta z filtru json_query, który wymaga, aby biblioteka jmespath była zainstalowana na Twoim hoście kontrolnym. Możesz zainstalować ją poleceniem pip install jmespath lub zainstalować za pomocą menedżera pakietów swojej dystrybucji, np. apt-get install python-jmespath.

Zarządzanie użytkownikami i ACL

Możesz używać tego skryptu do zarządzania użytkownikami i grupami w Proxmox VE (zarówno w instalacjach na pojedynczym serwerze, jak i w klastrach). Oto kilka przykładów.

pve_groups:
  - name: Admins
    comment: Administratorzy tego klastra PVE
  - name: api_users
  - name: test_users
pve_users:
  - name: root@pam
    email: [email protected]
  - name: lae@pam
    email: [email protected]
    firstname: Musee
    lastname: Ullah
    groups: [ "Admins" ]
  - name: pveapi@pve
    password: "Proxmox789"
    groups:
      - api_users
  - name: testapi@pve
    password: "Test456"
    enable: no
    groups:
      - api_users
      - test_users
  - name: tempuser@pam
    expire: 1514793600
    groups: [ "test_users" ]
    comment: "Tymczasowy użytkownik, którego ważność wygasa 2018-01-01 00:00:00 PST"
    email: [email protected]
    firstname: Test
    lastname: Użytkownik

Odnies się do library/proxmox_user.py link i library/proxmox_group.py link w celu dokumentacji modułu.

Do zarządzania rolami i ACL używany jest podobny moduł, ale główną różnicą jest to, że większość parametrów akceptuje tylko listy (może podlegać zmianom):

pve_roles:
  - name: Monitoring
    privileges:
      - "Sys.Modify"
      - "Sys.Audit"
      - "Datastore.Audit"
      - "VM.Monitor"
      - "VM.Audit"
pve_acls:
  - path: /
    roles: [ "Administrator" ]
    groups: [ "Admins" ]
  - path: /pools/testpool
    roles: [ "PVEAdmin" ]
    users:
      - pveapi@pve
    groups:
      - test_users

Odnies się do library/proxmox_role.py link oraz library/proxmox_acl.py link po dokumentację modułu.

Zarządzanie pamięcią

Możesz używać tego skryptu do zarządzania pamięcią w Proxmox VE (zarówno w instalacjach na pojedynczym serwerze, jak i w klastrach). Na razie wspierane są tylko typy dir, rbd, nfs, cephfs, lvm, lvmthin, zfspool, btrfs i cifs. Oto kilka przykładów.

pve_storages:
  - name: dir1
    type: dir
    content: [ "images", "iso", "backup" ]
    path: /ploup
    disable: no
    maxfiles: 4
  - name: ceph1
    type: rbd
    content: [ "images", "rootdir" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    username: admin
    pool: rbd
    krbd: yes
    monhost:
      - 10.0.0.1
      - 10.0.0.2
      - 10.0.0.3
  - name: nfs1
    type: nfs
    content: [ "images", "iso" ]
    server: 192.168.122.2
    export: /data
  - name: lvm1
    type: lvm
    content: [ "images", "rootdir" ]
    vgname: vg1
  - name: lvmthin1
    type: lvmthin
    content: [ "images", "rootdir" ]
    vgname: vg2
    thinpool: data
  - name: cephfs1
    type: cephfs
    content: [ "snippets", "vztmpl", "iso" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    monhost:
      - 10.0.0.1
      - 10.0.0.2
      - 10.0.0.3
  - name: pbs1
    type: pbs
    content: [ "backup" ]
    server: 192.168.122.2
    username: user@pbs
    password: PBSPassword1
    datastore: main
    namespace: Top/something # Opcjonalnie
  - name: zfs1
    type: zfspool
    content: [ "images", "rootdir" ]
    pool: rpool/data
    sparse: true
  - name: btrfs1
    type: btrfs
    content: [ "images", "rootdir" ]
    nodes: [ "lab-node01.local", "lab-node02.local" ]
    path: /mnt/proxmox_storage
    is_mountpoint: true
  - name: cifs1
    server: cifs-host.domain.tld
    type: cifs
    content: [ "snippets", "vztmpl", "iso" ]
    share: sharename
    subdir: /subdir
    username: user
    password: supersecurepass
    domain: addomain.tld

Refer to https://pve.proxmox.com/pve-docs/api-viewer/index.html po więcej informacji.

Obecnie typ zfspool można używać tylko do zawartości images i rootdir. Jeśli chcesz przechowywać inne typy zawartości na woluminie ZFS, musisz je określić z typem dir, ścieżka /<POOL>/<VOLUME> i dodać wpis w pve_zfs_create_volumes. Ten przykład dodaje przechowywanie iso na puli ZFS:

pve_zfs_create_volumes:
  - rpool/iso
pve_storages:
  - name: iso
    type: dir
    path: /rpool/iso
    content: [ "iso" ]

Odnies się do library/proxmox_storage.py link po dokumentację modułu.

Konfiguracja Ceph

Ta sekcja mogłaby być nieco lepiej skonstruowana. Jeśli aktywnie używasz tego skryptu do zarządzania swoim klastrem PVE Ceph, nie krępuj się uzupełnić tę sekcję i otworzyć prośbę o przyjęcie! Zobacz problem #68.

Zarządzanie Ceph PVE za pomocą tego skryptu jest eksperymentalne. Podczas gdy użytkownicy pomyślnie używali tego skryptu do wdrażania PVE Ceph, nie jest on w pełni testowany w CI (z powodu braku użytecznych dysków blokowych do wykorzystania jako OSD w Travis CI). Najpierw wdrażaj środowisko testowe z swoją konfiguracją przed produkcją i zgłaszaj wszelkie problemy, jeśli napotkasz jakiekolwiek.

Ten skrypt może skonfigurować system pamięci Ceph na Twoich hostach Proxmox. Poniższe definicje pokazują niektóre z konfiguracji, które są możliwe.

pve_ceph_enabled: true
pve_ceph_network: '172.10.0.0/24'
pve_ceph_cluster_network: '172.10.1.0/24'
pve_ceph_nodes: "ceph_nodes"
pve_ceph_osds:
  # OSD z wszystkim na tym samym urządzeniu
  - device: /dev/sdc
  # OSD z block.db/WAL na innym urządzeniu
  - device: /dev/sdd
    block.db: /dev/sdb1
  # zaszyfrowany OSD z wszystkim na tym samym urządzeniu
  - device: /dev/sdc
    encrypted: true
  # zaszyfrowany OSD z block.db/WAL na innym urządzeniu
  - device: /dev/sdd
    block.db: /dev/sdb1
    encrypted: true
# Reguły Crush dla różnych klas pamięci
# Domyślnie 'type' jest ustawione na hosta, można znaleźć poprawne typy na
# (https://docs.ceph.com/en/latest/rados/operations/crush-map/)
# wymienione w zakładce 'TYPES AND BUCKETS'
pve_ceph_crush_rules:
  - name: replicated_rule
    type: osd # To jest przykład jak można nadpisać istniejącą regułę
  - name: ssd
    class: ssd
    type: osd
    min-size: 2
    max-size: 8
  - name: hdd
    class: hdd
    type: host
# 2 pule Ceph dla dysków VM, które będą również definiowane jako pamięci Proxmox
# Używając różnych reguł CRUSH
pve_ceph_pools:
  - name: ssd
    pgs: 128
    rule: ssd
    application: rbd
    storage: true
  - name: hdd
    pgs: 32
    rule: hdd
    application: rbd
    storage: true
    size: 2
    min-size: 1
  - name: vm-storage
    pgs: 128
    rule: replicated_rule
    application: rbd
    autoscale_mode: "on"
    storage: true
pve_ceph_fs:
# System plików CephFS, który nie jest definiowany jako pamięć Proxmox
  - name: backup
    pgs: 64
    rule: hdd
    storage: false
    mountpoint: /srv/proxmox/backup

pve_ceph_network domyślnie wykorzystuje filtr ansible.utils.ipaddr, który wymaga, aby biblioteka netaddr była zainstalowana i używana przez Ansible kontrolera.

pve_ceph_nodes domyślnie wykorzystuje pve_group, ten parametr umożliwia określenie, na których węzłach zainstalować Ceph (np. jeśli nie chcesz instalować Ceph na wszystkich węzłach).

pve_ceph_osds domyślnie tworzy niezaszyfrowane woluminy ceph. Aby używać zaszyfrowanych woluminów, parametr encrypted musi być ustawiony na każdą z dysków na true.

PCIe Passthrough

Ten skrypt można skonfigurować, aby umożliwić przekazywanie urządzeń PCI z hosta Proxmox do VM-ów. Ta funkcja nie jest domyślnie włączona, ponieważ nie wszystkie płyty główne i procesory obsługują tę funkcję. Aby włączyć passthrough, urządzenia CPU muszą obsługiwać sprzętową wirtualizację (VT-d dla systemów opartych na Intelu i AMD-V dla systemów opartych na AMD). Odnies się do podręczników wszystkich komponentów, aby ustalić, czy ta funkcja jest obsługiwana czy nie. Konwencje nazewnictwa mogą się różnić, ale zazwyczaj są one odnajdywane jako IOMMU, VT-d, lub AMD-V.

Włączając tę funkcję, dedykowane urządzenia (takie jak GPU lub urządzenia USB) mogą być przekazywane do VM-ów. Oprócz dedykowanych urządzeń, różne zintegrowane urządzenia, takie jak zintegrowane GPU Intela lub AMD, również mogą być przekazywane do VM-ów.

Niektóre urządzenia mogą korzystać z użycia w trybie mediowanym. Urządzenia w trybie mediowanym można przekazywać do wielu VM-ów w celu dzielenia zasobów, pozostając jednocześnie użytecznymi przez system hosta. Podział urządzeń nie zawsze jest obsługiwany i powinien być walidowany przed włączeniem, aby zapobiec błędom. Odnies się do podręcznika urządzenia, które chcesz przekazać, aby ustalić, czy to urządzenie może korzystać z trybu mediowanego (Aktualnie ten skrypt obsługuje tylko GVT-g; SR-IOV nie jest aktualnie obsługiwane i musi być włączone ręcznie po zakończeniu roli).

Poniżej przedstawiamy przykładową konfigurację, która włącza PCIe passthrough:

pve_pcie_passthrough_enabled: true
pve_iommu_passthrough_mode: true
pve_iommu_unsafe_interrupts: false
pve_mediated_devices_enabled: false
pve_pcie_ovmf_enabled: false
pve_pci_device_ids:
  - id: "10de:1381"
  - id: "10de:0fbc"
pve_vfio_blacklist_drivers:
  - name: "radeon"
  - name: "nouveau"
  - name: "nvidia"
pve_pcie_ignore_msrs: false
pve_pcie_report_msrs: true

pve_pcie_passthrough_enabled jest wymagane, aby korzystać z jakiejkolwiek funkcjonalności PCIe passthrough. Bez tego włączonego, wszystkie inne powiązane z PCIe pola będą bezużyteczne.

pve_iommu_passthrough_mode włącza tryb passthrough IOMMU, co może zwiększyć wydajność urządzeń. Włączając tę funkcję, VM-y omijają domyślne tłumaczenie DMA, które normalnie byłoby wykonywane przez hipernadzorcę. Zamiast tego, VM-y przekazują żądania DMA bezpośrednio do sprzętowego IOMMU.

pve_iommu_unsafe_interrupts jest wymagany do włączenia PCI passthrough, jeśli system nie obsługuje mapowania przerwań. Możesz sprawdzić, czy urządzenie obsługuje mapowanie przerwań, używając polecenia dmesg | grep 'remapping'. Jeśli zobaczysz jeden z poniższych wierszy:

• "AMD-Vi: Interrupt remapping enabled"
• "DMAR-IR: Enabled IRQ remapping in x2apic mode" (x2apic może być inny na starych procesorach, ale powinno działać)

Wtedy wsparcie systemowe w zakresie mapowania przerwań jest obsługiwane i nie musisz włączać niespecjalnych przerwań. Zauważ, że włączenie tej wartości może spowodować niestabilność systemu.

pve_mediated_devices_enabled włącza wsparcie GVT-g dla zintegrowanych urządzeń, takich jak iGPU Intela. Nie wszystkie urządzenia obsługują GVT-g, dlatego zaleca się wcześniejszą weryfikację konkretnego urządzenia.

pve_pcie_ovmf_enabled włącza GPU OVMF PCI passthrough. Podczas korzystania z OVMF należy wybrać 'OVMF' jako opcję BIOS dla VM w Proxmox zamiast 'SeaBIOS'. To ustawienie spróbuje odrzucić urządzenia z arbitrażu VGA jeśli to możliwe.

pve_pci_device_ids to lista identyfikatorów urządzeń i dostawców, które chcesz przekazać do VM-ów z hosta. Zobacz sekcję 'GPU Passthrough' na WIKI Proxmox, aby znaleźć swoje konkretne identyfikatory urządzeń i dostawców. Ustawiając tę wartość, należy określić 'id' dla każdego nowego elementu w tablicy.

pve_vfio_blacklist_drivers to lista sterowników, które mają być исключzone/zablokowane w hosta. To jest wymagane, gdy przekazujesz urządzenie PCI, aby zapobiec jego użyciu przez hosta przed przypisaniem go do VM. Ustawiając tę wartość, należy określić 'name' dla każdego nowego elementu w tablicy.

pve_pcie_ignore_msrs zapobiega awariom VM-u dla niektórych aplikacji systemu Windows, takich jak GeForce Experience, Passmark Performance Test i SiSoftware Sandra. Ta wartość jest wymagana tylko przy przekazywaniu urządzeń PCI do systemów opartych na Windows.

pve_pcie_report_msrs może być używana do włączania lub wyłączania logowania komunikatów ostrzeżeń o msrs. Jeśli zauważasz wiele komunikatów ostrzeżeń w dzienniku syst тем 'dmesg', ten parametr można wykorzystać do wyciszenia ostrzeżeń o msrs.

Notatki Dewelopera

Podczas rozwijania nowych funkcji lub naprawiania czegokolwiek w tym skrypcie, możesz przetestować swoje zmiany za pomocą Vagranta (obecnie wspierany jest tylko libvirt). Skrypt można znaleźć w tests/vagrant (więc upewnij się, że dostosujesz zmienne grupowe jak potrzeba). Upewnij się, że testujesz wszelkie zmiany zarówno na Debianie 10, jak i 11 (zaktualizuj Vagrantfile lokalnie, aby użyć debian/buster64) przed przesłaniem pull requesta.

Możesz również określić lokalny proxy dla cachowania apt (np. apt-cacher-ng, które musi działać na porcie 3142), aby przyspieszyć pobieranie pakietów, jeśli masz je uruchomione w swojej lokalizacji. Vagrant dokonuje wykrycia, czy lokalny proxy cachowania jest dostępne i używa go tylko wtedy, gdy jest on dostępny w twojej sieci, więc możesz po prostu na stałe ustawić tę zmienną w swoim środowisku programistycznym, jeśli wolisz.

Na przykład, możesz uruchomić następujące polecenie, aby uzyskać bardziej zrozumiałe wyjście, użyć proxy cachowania i utrzymać VM-y uruchomione, jeśli napotkasz błąd (abyś mógł go rozwiązać i/lub uruchomić vagrant provision po naprawie):

APT_CACHE_HOST=10.71.71.10 ANSIBLE_STDOUT_CALLBACK=debug vagrant up --no-destroy-on-error

Współtwórcy

Musee Ullah (@lae, lae@lae.is) - Główny deweloper
Fabien Brachere (@Fbrachere) - Wsparcie dla konfiguracji pamięci
Gaudenz Steinlin (@gaundez) - Wsparcie dla Ceph itd.
Richard Scott (@zenntrix) - Wsparcie dla Ceph, wsparcie dla PVE 7.x itd.
Thoralf Rickert-Wendt (@trickert76) - Wsparcie dla PVE 6.x itd.
Engin Dumlu (@roadrunner)
Jonas Meurer (@mejo-)
Ondrej Flidr (@SniperCZE)
niko2 (@niko2)
Christian Aublet (@caublet)
Gille Pietri (@gilou)
Michael Holasek (@mholasek)
Alexander Petermann (@lexxxel) - Wsparcie dla PVE 8.x itd.
Bruno Travouillon (@btravouillon) - Poprawa UX
Tobias Negd (@wu3rstle) - Wsparcie dla Ceph
PendaGTP (@PendaGTP) - Wsparcie dla Ceph
John Marion (@jmariondev)
foerkede (@foerkede) - Wsparcie dla pamięci ZFS
Guiffo Joel (@futuriste) - Wsparcie dla konfiguracji pul
Adam Delo (@ol3d) - Wsparcie dla PCIe Passthrough

Pełna lista współtwórców

[linki referencyjne]: