Proxmox Otomasyonu Faz 2.5: Depolamayı Güçlendirme, Doğrulama, fstab Kalıcılığı ve 5. Disk

Proxmox Otomasyon Serisi Faz 2.5 Girişi

Bu rehber, Proxmox Otomasyon Serisi'nin üçüncü modülüdür. Faz 2 saha oturumu, depolama mimarinin canlı ortamda kanıtlanmasıyla noktalanmıştı: Terraform üzerinde seri numaralarıyla (serial) tanımlanan dört disk, idempotent bir Ansible playbook aracılığıyla LVM ve XFS katmanlarından geçirilip /srv/* altına bağlanmış, çalışan sanal makinede (VM) disk boyutu 20 GB'den 30 GB'ye kesintisiz büyütülmüş ve her iddianın arkasına somut terminal çıktıları konmuştu.

Fstab Kalıcılığı ve Doğrulama

Bu sağlam bir zemin olsa da Faz 2 tamamlandığında arkasındaki iki büyük varsayım ve bir mimari açıyı hâlâ açık bırakıyordu: Reboot Kalıcılık Testi. Dosya sistemlerinin reboot sonrasında geri geleceği varsayılıyordu. fstab satırları yazılmış ve LVM'in açılışta volume group'ları otomatik etkinleştirmesi bekleniyordu; fakat birisi makineyi gerçekten yeniden başlatıp kontrol etmekle yetinmişti.

Üretim ortamlarındaki veritabanı sunucularında "makine reboot oldu ve veri diskleri geri gelmedi" durumu klasik bir kriz senaryosudur ve neredeyse her zaman tek satırlık bir hatadan kaynaklanır: fstab'da bir yazım yanlışı, aktivasyon kapsamı dışında kalan bir VG veya açılış sürecinin bağlamayı reddettiği bir dosya sistemi.

Depolama Düzenini Tek Bir Kaynaktan

Yapılandırma Kayması Riski (Configuration Drift) projesi, depolama düzeni 02_storage.yml playbook'unun içindeki vars sayesinde çözüldü. Tek bir playbook varken bu durum sorunsuzdu; ancak aynı listeyi doğrulayan ikinci bir playbook geldiği anda iki dosya arasında kopyala-yapıştır yapmak kaçınılmaz bir drift riskine davetiye çıkarır.

Bu sağlamlaştırma adımı, çalışan parçaları bozmadan bu üç açığı kapatır: Disk düzeni tek gerçek kaynak (Single Source of Truth) olarak group_vars/provisioned.yml dosyasına taşınır.

Playbook Değişiklikleri

ansible/playbooks/02_storage.yml (v3) güncellendi. data_disks listesi group_vars 'a taşındı; dosya eksikse açık bir mesajla süreci durduran koruyucu assert eklendi. Görevler v2 ile aynı kaldı.

ansible/playbooks/03_storage_verify.yml (yeni (v1.1)) Reboot sonrası kalıcılık doğrulaması olarak güncellendi. Yeni (v1.1) Reboot sonrası kalıcılık doğrulaması: doğrulama token'ları, reboot, taze fact'ler, assertion'lar ve doğrulama logları. İlk saha testinde tespit edilen follow: true düzeltmesini içerir.

terraform/variables.tf güncellendi. Yeni değişken: scratch_disk_size_gb (varsayılan: 0 = 5. disk kapalı).

terraform/vm.tf güncellendi. Değişken sıfırdan büyük olduğunda scsi5 arayüzünde scratch01 serial'li diski üreten dinamik blok ( dynamic "disk" ).

terraform/terraform.tfvars.example güncellendi. 5. diskin büyüme iş akışıyla birlikte belgelenen yeni parametre.

LVM ve Volüm Kontrolü

Neden lv_attr karakterleri değil? LVM, volüm durumunu lv_attr öznitelik dizgisinin 5. karakterinde kodlar ( a = active). Ancak pozisyona dayalı karakter okumak, araçlar raporlama düzenini değiştirdiğinde sessizce patlayan kırılgan bir yöntemdir. Playbook bunun yerine lvs komutundan JSON raporu alarak volüm sayısını doğrular, ardından sistemin doğrudan kendisine sorar: aktif bir mantıksal volüm aygıt düğümünü /dev/vg/lv altında sunar, aktif olmayan bir volümün düğümü oluşmaz.

Bu yüzden her volüm için stat çalıştırmak hem daha sade hem de daha güvenilir bir testtir.

- name: Read the LVM logical volume report (JSON)
  ansible.builtin.command:
    cmd: lvs --reportformat json --noheadings
    output: vg_name,lv_name,lv_attr
  register: lvs_state

- name: Parse the LVM report
  ansible.builtin.set_fact:
    lv_rows: "{{ (lvs_state.stdout | from_json).report[0].lv }}"

- name: Exactly the expected logical volumes must exist
  ansible.builtin.assert:
    that: lv_rows | length == data_disks | length

- name: Check every logical volume's device node
  ansible.builtin.stat:
    path: "/dev/{{ item.vg }}/{{ item.lv }}"
    follow: true
  loop: "{{ data_disks }}"
  register: lv_nodes

- name: Every logical volume must be active after the reboot
  ansible.builtin.assert:
    that: lv_nodes.results[idx].stat.exists and lv_nodes.results[idx].stat.isblk

Reboot Testi ve Smoke Test

Reboot öncesi belirteçler (token & marker) kalıcılığı dizin adıyla değil içerikle denetlemek gerekir. Playbook, reboot öncesi her dosya sistemine benzersiz bir token yazar:

- name: Mint a one-run verification token
  ansible.builtin.set_fact:
    verify_token: "phase2-{{ ansible_facts.date_time.epoch }}-{{ 100000 | random }}"

- name: Write a marker file into every data filesystem
  ansible.builtin.copy:
    content: "{{ item.mount }} {{ verify_token }}"
    dest: "{{ item.mount }}/phase2-verify.txt"
    mode: "0644"
  loop: "{{ data_disks }}"

Verify_reboot parametresi playbook'ların başında konulur. Gerekli koşul olarak | bool filtresi kullanılır.

Kapsamlı Yapılandırma ve Dinamik Envanter

Faz 4, dinamik envanter (Faz 4) olarak terim olarak geçer. Depolama düzeni ansible/inventory/group_vars/provisioned.yml dosyasında yaşar. Bu dosyanın var olup olmadığını ve playbook'un provisioned grubuna karşı çalıştırdığını kontrol etmeniz gerekir.

Playbook İçi Önemli Değişiklikler

• playbooks/02_storage.yml (kurulum): data_disks listesi group_vars 'a'ı taşıdı ve dosya eksikse koruyucu assert ekledi.
• playbooks/03_storage_verify.yml (reboot kalıcılığı kanıtı): v1.1 sürümüyle güncellendi. Smoke test modu için -e verify_reboot=false parametresi kullanılır.
• terraform/variables.tf: scratch_disk_size_gb değişkeni eklendi (varsayılan: 0 = 5. disk kapalı).
• terraform/vm.tf: scsi5 arayüzünde scratch01 serial'li diski üreten dinamik "disk" bloku oluşturuldu.

LVM Aktivasyon Kontrolü

LVM aktivasyonu için systemctl status lvm2-activation.service komutu ile doğrudan VM'de kontrol edilebilir. Ayrıca vgchange -ay ile tüm volüm gruplarının aktif durumu kontrol edilebilir.

Sonuç

Bu yapılandırma, Faz 2'deki disk büyüme senaryosunun yanı sıra, yeni bir LUN eklenme durumunda da güvenli bir birim yönetimi sağlar. Tek bir listeyi tek bir playbook ile okuyan iki playbook, group_vars/provisioned.yml üzerinden tek gerçek kaynak (Single Source of Truth) oluşturarak yapılandırma kayması riskini minimize eder.