Bu rehber, Proxmox Otomasyon Serisi'nin üçüncü modülüdür. Faz 2 saha oturumu, depolama mimarisinin 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.
Bu sağlam bir zemin olsa da Faz 2 tamamlandığında arkasında henüz test edilmemiş iki büyük varsayım ve bir mimari açık bırakmıştı:
-
Reboot Kalıcılık Testi: Dosya sistemlerinin reboot sonrasında geri geleceği varsayılıyordu.
fstabsatı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 edene kadar bu bir kanıt değil, bir temenniden ibarettir. Ü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. - Yeni Disk İhtiyacı: Faz 2'deki büyüme senaryosu mevcut bir diski büyütmeyi kapsıyordu. Oysa sahada depolama büyümesi sıklıkla ortama yeni bir diskin eklenmesi şeklinde gelir: yeni bir iş yükü için depolama ekibinden gelen taze bir LUN.
-
Yapılandırma Kayması Riski (Configuration Drift): Depolama düzeni
02_storage.ymlplaybook'unun içindekivars:bloğunda tanımlanmıştı. Tek bir playbook varken bu durum sorunsuzdu; ancak aynı listeyi doğrulayacak ikinci bir playbook geldiği anda iki dosya arasında kopyala-yapıştır yapmak kaçınılmaz bir drift riskine davetiye çıkaracaktı.
Bu sağlamlaştırma adımı, çalışan parçaları bozmadan bu üç açığı kapatıyor:
- Disk düzeni tek gerçek kaynak (Single Source of Truth) olarak
group_vars/provisioned.ymldosyasına taşınıyor. - Yeni yazılan
03_storage_verify.ymlplaybook'u makineyi yeniden başlatarak reboot sonrası kalıcılığını doğrulama token'ları, güncel fact'ler ve assertion'lar ile kanıtlıyor. - Opsiyonel bir beşinci disk ise uçtan uca yeni disk ekleme iş akışını sınıyor.
| Dosya | Değişiklik | Amaç |
|---|---|---|
ansible/inventory/group_vars/provisioned.yml |
Yeni | Depolama düzenini tek bir liste olarak tanımlar: serial, vg, lv, mount. Hem kurulum hem doğrulama playbook'ları buradan okur. |
ansible/playbooks/02_storage.yml |
Güncellendi (v3) |
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ı: 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 parametresi. |
Kapsam sınırları yine bilinçli olarak dar tutuldu:
| Kapsam Dahilinde | Kapsam Dışında |
|---|---|
Kurulum ve doğrulama playbook'larının paylaştığı tek group_vars listesi |
Terraform state'ten beslenen dinamik envanter (Faz 4) |
| Senaryolaştırılmış reboot ile boot kalıcılığının kanıtlanması | Dosya sistemi kullanımının sürekli izlenmesi (Zabbix Faz 3'te geliyor) |
tfvars parametresiyle kontrol edilen opsiyonel beşinci disk |
Disk silme veya küçültme |
02, 03 ve büyüme çalıştırmalarının gerçek saha logları (ok=15 changed=1, ok=28 changed=2 failed=0, büyümede ok=15 changed=5) |
Rebootsuz hızlı test modunun logları (verify_reboot=false belgelendi, henüz sahada loglanmadı) |
Depolama Düzeni İçin Tek Gerçek Kaynak
Faz 2 playbook'u disk listesini play başındaki bir vars: bloğunda tanımlamıştı. İkinci bir playbook aynı bilgiye ihtiyaç duyduğu anda sorun başlar: doğrulama playbook'unun da aynı serial'lere, aynı VG/LV adlarına ve aynı bağlama noktalarına ihtiyacı vardır; çünkü altyapıyı kanıtlamak, kurulum playbook'unun kurduğunu iddia ettiği şeyi birebir denetlemek demektir. İki dosyada tek bir listenin kopyasını tutmak drift'in doğduğu yerdir: beşinci bir disk eklersiniz, bir playbook'u günceller, diğerini unutursunuz ve doğrulama adımı fark ettirmeden o diski denetlemeyi bırakır.
Çözüm standart Ansible yöntemidir: grup değişkenleri (group_vars). Envanter zaten provisioned adında bir grup tanımlıyor; bu nedenle inventory/group_vars/provisioned.yml konumundaki bir dosya, hiçbir playbook kodu çalışmadan önce o gruptaki her host için otomatik olarak yüklenir. İki playbook da artık doğrudan data_disks değişkenini okur ve mimari bir garanti elde edilir: depoda tek bir liste vardır.
# ansible/inventory/group_vars/provisioned.yml
# Faz 2 depolama düzeni için tek gerçek kaynak (Single Source of Truth).
# playbooks/02_storage.yml (kurulum) ve
# playbooks/03_storage_verify.yml (reboot kalıcılığı kanıtı) tarafından okunur.
data_disks:
- serial: var01 # scsi1, boyut: var_disk_size_gb
vg: vg_var
lv: lv_var
mount: /srv/var
- serial: log01 # scsi2, boyut: log_disk_size_gb
vg: vg_log
lv: lv_log
mount: /srv/log
- serial: data01 # scsi3, boyut: data_disk_size_gb
vg: vg_data
lv: lv_data
mount: /srv/data
- serial: backup01 # scsi4, boyut: backup_disk_size_gb
vg: vg_backup
lv: lv_backup
mount: /srv/backup
# 03_storage_verify.yml varsayılan olarak makineyi reboot eder.
# Kesintisiz hızlı kontrol (smoke test):
# ansible-playbook playbooks/03_storage_verify.yml -e verify_reboot=false
verify_reboot: true
Bu dosyadaki yorum satırları SCSI arayüzünü ve tfvars değişkenini her serial'in yanında tutar; çünkü bu dosya Terraform tarafı ile Ansible tarafı arasındaki bir sözleşmedir. verify_reboot değişkeni de playbook'un derinliklerine gömülmek yerine buraya kondu; böylece operatör ayarları aradığı yerde bulur.
Listeyi playbook dışına taşımak dosya bulunamadığında ne olacağını değiştirir; bu yüzden her iki playbook da en başta bir koruyucu assert ile açılır. Yanlış dizinden ya da bu grubu içermeyen bir envanterle çalıştırma durumunda süreç ortalarda tanımsız değişken hatasıyla patlamak yerine, henüz hiçbir şeye dokunmadan neden durduğunu açıkça bildirir:
- name: Require the storage layout (group_vars/provisioned.yml)
ansible.builtin.assert:
that: data_disks is defined and data_disks | length > 0
fail_msg: >-
data_disks tanımlanmamış. Depolama düzeni
ansible/inventory/group_vars/provisioned.yml dosyasında yaşar;
bu dosyanın var olduğunu ve playbook'un reponun kendi ansible.cfg'siyle,
provisioned grubuna karşı çalıştırıldığını kontrol edin.
Ansible öncelik sıralaması (precedence) burada kritik bir tasarım kararı içerir:
| Öncelik (Düşükten Yükseğe) | Bu Tasarımdaki Anlamı |
|---|---|
group_vars/provisioned.yml |
Tek gerçek kaynak; her iki playbook da olduğu gibi okur. |
Playbook içindeki vars:
|
group_vars'ı override eder; 02_storage.yml içinden özellikle kaldırıldı ki dosyadaki listeyle yarışamasın. |
Komut satırındaki --extra-vars
|
Her şeyi override eder; tek seferlik geçici denemeler için belgelenmiş kaçış kapısı (-e verify_reboot=false). |
Reboot Testi: 03_storage_verify.yml
Faz 2 saha oturumu depolama katmanını bırakıldığı anki haliyle doğrulamıştı: bağlı, boyutlandırılmış ve df üzerinden okunabilir durumda. Ancak makinenin bir reboot sonrasında ayağa kalkıp kalkmayacağı test edilmemişti.
fstab girdileri yalnızca açılışta okunur. Açılıştaki LVM aktivasyonu, kurulum playbook'unun tetiklediği açık çalıştırmadan tamamen farklı bir mekanizmadır. Elle mount komutu çalıştırıldığı için ayakta duran bir dosya sistemi ile kalıcı olan bir dosya sistemi, ilk yeniden başlatmaya kadar birbirinden ayırt edilemez.
Doğrulama playbook'u, dikkatli bir sistem mühendisinin elle yapacağı adımları tekrarlanabilir çıktılara döker.
Reboot Öncesi Belirteçler (Token & Marker)
Kalıcılığı dizin adıyla değil içerikle denetlemek gerekir; çünkü yeni formatlanmış boş bir disk de aynı mount point'e bağlanabilir ama içindeki veriyi kaybetmiştir. Playbook, reboot öncesinde 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 }}"
Token, her çalıştırmanın yalnızca kendi yazdığını doğrulaması için üretilir. Sabit bir string'e karşı kontrol yapmak önceki çalıştırmadan kalan bayat bir dosyada bile geçer; oysa reboot'tan saniyeler önce üretilen bir token'ı aramak, okunan verinin tam o oturumda diske yazıldığını garantiler. Dosya içeriği mount yolu ile token'ın birleşimidir; yani yanlışlıkla başka diske yazılan bir belirteç de doğrulamadan geçemez.
Reboot ve Fact Yenileme Mantığı
- name: Reboot the VM (the moment of truth for fstab and LVM)
ansible.builtin.reboot:
msg: "Phase 2 verification reboot: proving fstab + LVM boot persistence"
pre_reboot_delay: 5
post_reboot_delay: 10
reboot_timeout: 600
test_command: "uptime"
when: verify_reboot | default(true) | bool
- name: Refresh facts after the reboot (pre-reboot facts are stale)
ansible.builtin.setup:
when: verify_reboot | default(true) | bool
Bu iki görevde iki hayati teknik detay bulunur:
-
ansible.builtin.setupgörevi gereksiz görünür ama zorunludur.gather_factsplay'in en başında tek bir kez çalışır; dolayısıyla reboot sonrasındaansible_facts.mountslistesi hâlâ makinenin açılış öncesi dünyasını tarif eder. Reboot sonrasısetupmodülünü çağırmak, mount kontrollerinin güncel gerçeği okumasını sağlar. - Koşulda yer alan
| boolfiltresi zorunludur. Komut satırından--extra-varsile geçilen değerler Ansible'a string olarak ulaşır. Jinja motorunda"false"string'i truthy (doğru kabul edilen) bir değerdir; bu filtre konmazsa-e verify_reboot=falseparametresi verildiğinde playbook tam da reboot etmemesini istediğiniz anda makineyi yeniden başlatır.
LVM 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 daha güvenilir bir testtir.
- name: Read the LVM logical volume report (JSON)
ansible.builtin.command:
cmd: lvs --reportformat json --noheadings -o vg_name,lv_name,lv_attr
register: lvs_state
changed_when: false
- 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 # /dev/vg/lv -> /dev/dm-X symlink'ini takip etmek şart
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
- lv_nodes.results[idx].stat.isblk
fail_msg: >-
The volume group {{ item.vg }} was not activated after the reboot.
Diagnose inside the VM with: systemctl status lvm2-activation.service,
then check vgchange -ay.
loop: "{{ data_disks }}"
loop_control: { index_var: idx }
İlk saha oturumunun öğrettiği follow: true dersi tam buraya aittir. /dev/vg/lv bir blok aygıtı değil, udev tarafından yönetilen bir sembolik bağdır (symlink). stat modülüne symlink'i takip etmesi söylenmediğinde bağın kendisini inceler; sonuç olarak islnk: true dönerken isblk: false kalır ve çalışan sistemde sahte bir alarm (false positive) üretir.
fstab kontrolü ise mount modülünün yazdığı satırı doğrudan denetler: /dev/mapper alias'ı yerine verilen tam aygıt yolu (/dev/vg_data/lv_data) ve bağlama noktası. Hem aygıtı hem hedefi aramak iki arıza modunu birden yakalar: satırın hiç olmaması veya olup yanlış yere işaret etmesi.
Kesintisiz Hızlı Kontrol Modu (verify_reboot=false)
Reboot istenmeyen anlarda playbook -e verify_reboot=false ile çalıştırılarak kesintisiz bir denetim aracına (smoke test) dönüşür. Bu modda hangi kontrolün neyi kanıtladığı net biçimde bilinmelidir:
| Denetim | Reboot İle (Varsayılan) |
verify_reboot=false İle (Smoke Test) |
|---|---|---|
| Belirteç dosyaları (byte-to-byte) | Veri açılışı atlattı | Yalnızca oturum içi doğrulama |
Mount durumu (fstype: xfs) |
fstab açılış aktivasyonu çalıştı |
Mevcut bağlı durum doğru |
| LV aygıt düğümleri mevcut | Açılış zamanı LVM aktivasyonu çalıştı | LV'ler şu anda aktif |
fstab satırları mevcut |
Kalıcılık beyan edilmiş, sadece canlıda kalmamış | Aynı |
| Serial'ler tek diske çözülüyor | Kimlik şeması açılışı atlattı | Kimlik şeması şu an geçerli |
Dört Diskten Fazlası: scratch01 Genişletme İş Akışı
Faz 2'deki büyütme senaryosu en yaygın talebi yanıtlamıştı: aynı diski büyütmek. İkinci yaygın talep ise yeni bir iş yükü için yeni bir disk eklemektir.
Manuel dünyada bu işlem hipervizörde ayrı, guest içinde ayrı konsol adımları demektir ve aygıt harfi tahmin oyununun en çok can sıktığı yerdir; çünkü yeni bir disk kendisinden sonraki disklerin sıralamasını kaydırabilir.
Terraform tarafı bunu dinamik bir blokla çözer. HCL blok seviyesinde doğrudan if anahtarı sunmaz; bu yüzden parametre verildiğinde tek elemanlı, verilmediğinde boş liste dönen bir dynamic "disk" bloğu kullanılır. Varsayılan sıfırken plan içinde scsi5 diski hiç yer almaz:
# terraform/vm.tf (Opsiyonel 5. veri diski)
variable "scratch_disk_size_gb" {
description = "Opsiyonel 5. veri diski (serial: scratch01), GB. 0 = kapali."
type = number
default = 0
}
# proxmox_virtual_environment_vm.test_vm kaynagi icinde:
dynamic "disk" {
for_each = var.scratch_disk_size_gb > 0 ? [var.scratch_disk_size_gb] : []
content {
datastore_id = var.storage_id
interface = "scsi5"
size = disk.value
serial = "scratch01"
ssd = true
discard = "on"
}
}
Ansible tarafında yeni kod yazılmaz, sadece sözleşmeye yeni bir satır eklenir. Sorumluluk dağılımı bellidir:
| Taraf | Sorumluluk Alanı | Tanımlandığı Yer |
|---|---|---|
| Terraform | Hangi disklerin var olduğu, arayüzler, boyutlar, serial'ler |
terraform/vm.tf + tfvars ayarları |
| Ansible | Her serial'in guest içinde neye dönüştüğü: vg, lv, mount noktası |
inventory/group_vars/provisioned.yml |
| Kernel | Her serial'in o anda hangi disk harfi olduğu | Her çalıştırmada sıfırdan çözülür, asla kalıcı yazılmaz |
Büyütme (Resize) ile Yeni Disk Ekleme (Attach) Arasındaki Asimetri
Saha oturumu bu iki eylem arasındaki farkı netleştirdi:
| Operasyon | VM Durumu | Serial Guest'te Görünür mü? | Görünmezse Yapılacak Eylem |
|---|---|---|---|
Mevcut diski büyütmek (data 20 -> 30 GB) |
Çalışıyor (Online) | Anında (Kernel görünümü anında yenilenir) | Gerek yok; sahada kanıtlanmış online işlem |
Yeni disk takmak (scsi5 scratch01) |
Çalışıyor (Online) | Tam bir VM başlatması gerektirebilir (saha oturumunda: anında görüldü) | PVE host üzerinde: qm shutdown 200 && qm start 200, sonra 02'yi tekrar çalıştır |
| Tam bir VM başlatmasından sonraki durum | Taze başladı | Her zaman (konfigürasyon ve QEMU hemfikir) | Teşhis: `qm config 200 |
Büyütme online, yeni takma da (genellikle) online:
Mevcut diski büyütmek tamamen kesintisiz kalır. Yeni disk takmak da saha oturumunda makine çalışırken online tamamlandı; ancak serial'in konfigürasyonun gerisinde kaldığı durumlar için belgelenmiş tam kapat-aç adımı el altında beklemelidir.
Uçtan uca büyüme iş akışı:
{% raw %}
# 1. ctrl-01'de: diski aktif et (terraform/terraform.tfvars)
scratch_disk_size_gb = 5
# 2. apply: disk makine calisirken takilir
cd ~/proxmox-automation/terraform && terraform apply
# 3. duzen girdisini group_vars/provisioned.yml dosyasina ekle
# - serial: scratch01
# vg: vg_scratch
# lv: lv_scratch
# mount: /srv/scratch
# 4. baglamayi insa et (ayni playbook, fazladan bir dongu iterasyonu)
cd ../ansible && ansible-playbook playbooks/02_storage.yml
# 5. Eger 4. adim scratch01 NOT FOUND derse: PVE node'unda tam durdur/baslat
# qm shutdown 200 && qm start 200
# ardindan 4. adimi tekrar calistir
# 6. reboot dahil kanitla
ansible-playbook playbooks/03_storage_verify.yml
ssh ubuntu@192.168.122.50 'df -h /srv/scratch'
Upstream İmaj Yenilenmesi Durumu
Beşinci diski takarken çalıştırılan apply, plan çıktısında beklenmedik bir satır getirdi: Plan: 1 to add, 2 to change, 1 to destroy.
Yok edilen nesne VM değildi; proxmox_download_file.ubuntu_image kaynağıydı. Canonical, Ubuntu cloud imajını upstream depoda güncellemiş, dosya boyutu 861.837.824 bayttan 864.818.688 bayta çıkmıştı. Provider boyut uyuşmazlığını görünce eski dosyayı silip yenisini indirdi. Apply süresi bu indirme nedeniyle 5 dakika sürdü; fakat VM yerinde güncellendi, kesinti yaşanmadı. Bu tazelik yerine tam tekrarlanabilirlik isteyenler template.tf içinde overwrite = false parametresini kullanabilir.
Saha Oturumu ve Terminal Çıktıları
Aşağıdaki runbook tablosu Faz 2 Addendum'un sahadaki tam icra sırasıdır:
| Makine | Komut | Geri Alınan Çıktı | Durum |
|---|---|---|---|
ctrl-01 |
cd ~/proxmox-automation && unzip -o proxmox-automation.zip |
Dosyalar güncellendi | Tamamlandı |
ctrl-01 |
cd ansible && ansible-playbook playbooks/02_storage.yml |
PLAY RECAP | Saha: ok=15 changed=1
|
ctrl-01 |
ansible-playbook playbooks/03_storage_verify.yml |
Debug satırları, assert satırları, PLAY RECAP | Saha: ok=28 changed=2 failed=0
|
ctrl-01 |
ansible-playbook playbooks/03_storage_verify.yml -e verify_reboot=false |
Rebootsuz mod recap çıktısı | Opsiyonel, henüz çalıştırılmadı |
ctrl-01 |
tfvars düzenle: scratch_disk_size_gb = 5, sonra terraform apply
|
Apply çıktısı (imaj tazeleme + scsi5, VM yerinde) | Saha: tamamlandı (5 dk: imaj indirme) |
ctrl-01 |
scratch01'i group_vars'a ekle, 02_storage.yml tekrar çalıştır |
scratch01 mapping satırı, PLAY RECAP |
Saha: ok=15 changed=5
|
ok=14'ten ok=15'e Geçişin Mantığı
Faz 2 rehberinde 02_storage.yml için recap ok=14 changed=1 olarak kaydedilmişti. v3 refactor'ünde liste group_vars'a taşındı ve play başına koruyucu assert görevi eklendi. Geçen bir assertion recap'te fazladan bir ok demektir: 14 görev artı koruyucu assert eşittir 15. Depolama işinin kendisinde hiçbir şey değişmedi; recap'ler arasındaki bir görevlik fark, group_vars hamlesinin sisteme gizli bir yük bindirmediğinin somut kanıtıdır.
root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/02_storage.yml
# ... eslestirme ve kontroller gecti ...
TASK [Create/resize physical volumes] ******************************************
changed: [vm-test-01] => (item=var01)
changed: [vm-test-01] => (item=log01)
changed: [vm-test-01] => (item=data01)
changed: [vm-test-01] => (item=backup01) # pvresize gecisi
PLAY RECAP *********************************************************************
vm-test-01 : ok=15 changed=1 unreachable=0 failed=0
İlk Doğrulama Denemesi ve Düzeltme Adımı
İlk doğrulama denemesi reboot'a kadar yeşil aktı: token'lar yazıldı, eşleşme alındı, makine yeniden başladı, token'lar byte'ı byte'ına geri okundu. Ancak mantıksal volüm kontrolünde sistem sahte bir alarmla (false positive) durdu:
root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/03_storage_verify.yml
TASK [Every logical volume must be active after the reboot] ********************
fatal: [vm-test-01]: FAILED! => (item=vg_var/lv_var) => {
"assertion": "lv_nodes.results[0].stat.isblk",
"evaluated_to": false,
"msg": "The volume group vg_var was not activated after the reboot ..."
}
# ... (vg_log, vg_data, vg_backup: dördü birden ayni anda basarisiz)
PLAY RECAP *********************************************************************
vm-test-01 : ok=18 changed=2 unreachable=0 failed=1
follow: true eklenip düzeltme doğrulandıktan sonra ikinci deneme başarıyla sonuçlandı:
root@ctrl-01:~/proxmox-automation/ansible# grep "follow:" playbooks/03_storage_verify.yml
follow: true
root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/03_storage_verify.yml
TASK [Show the mapping before the reboot] **************************************
ok: [vm-test-01] => (item=var01) => { "msg": "var01 = /dev/sde" }
# ... (log01 = /dev/sdd, data01 = /dev/sdc, backup01 = /dev/sdb)
TASK [Reboot the VM (the moment of truth ...)] *********************************
changed: [vm-test-01]
TASK [Every logical volume must be active after the reboot] ********************
ok: [vm-test-01] => (item=vg_var/lv_var) => { "msg": "All assertions passed" }
# ... (vg_log/lv_log, vg_data/lv_data, vg_backup/lv_backup)
TASK [Show the mapping before vs after ...] ************************************
ok: [vm-test-01] => (item=var01) => { "msg": "var01: /dev/sde before -> /dev/sde after (vg_var/lv_var on /srv/var)" }
ok: [vm-test-01] => (item=backup01) => { "msg": "backup01: /dev/sdb before -> /dev/sdb after (vg_backup/lv_backup on /srv/backup)" }
# ... (log01, data01)
PLAY RECAP *********************************************************************
vm-test-01 : ok=28 changed=2 unreachable=0 failed=0
Buradaki sayılar net bir hesaba dayanır:
-
changed=2: Doğrulama çalıştırması için beklenen minimumdur; token dosyaları her çalıştırmada taze yazılır verebootmodülü gerçek bir eylemdir. -
ok=28: İlk denemedekiok=18'in üzerine 10 yeni kontrol eklenmedi; ilk deneme assert'te durduğu için çalışamayan boot sonrası eşleşme,fstabçıktıları,findmnt,lsblkvedfgörevleri nihayet çalışabildi.
Bu ikinci denemede harfler de değişmedi (var01 hem öncesinde hem sonrasında sde); ama bu bir garanti değil, o boot'a özgü bir şans. Şema harflerin sabit kalmasına değil, sadece serial'lerin sabit kalmasına güveniyor; birkaç bölüm sonraki büyüme çalıştırması, harfler gerçekten döndüğünde de aynı yeşil sonucu veriyor.
Genişletme Çalıştırması: Aygıt Harflerinin Kayması Testi
scratch_disk_size_gb = 5 ile disk eklendikten sonra 02_storage.yml çalıştırıldı:
root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/02_storage.yml
TASK [Show the serial to device mapping ...] ***********************************
ok: [vm-test-01] => (item=scratch01) => { "msg": "scratch01 (vg_scratch/lv_scratch -> /srv/scratch) = /dev/sdf" }
TASK [Create volume groups (one per disk)] *************************************
changed: [vm-test-01] => (item=vg_scratch)
# (vg_var, vg_log, vg_data, vg_backup: ok, dokunulmadi)
PLAY RECAP *********************************************************************
vm-test-01 : ok=15 changed=5 unreachable=0 failed=0
changed=5 tam olarak yeni bir diskin ilk çalıştırma işini yapan beş görevdir: PV görevi (pvresize geçişi), VG, LV, XFS ve mount. Mevcut dört disk hiçbir değişiklik bildirmedi; VG, LV, XFS ve mount maddeleri ok olarak döndü.
Ardından çalıştırılan doğrulama playbook'u, bu tasarımın en büyük sınavını verdi. Beşinci disk takıldıktan sonra yapılan reboot sırasında kernel aygıt harflerini tamamen döndürdü:
root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/03_storage_verify.yml
TASK [Show the mapping before vs after ...] ************************************
ok: [vm-test-01] => (item=var01) => { "msg": "var01: /dev/sde before -> /dev/sdf after (vg_var/lv_var on /srv/var)" }
ok: [vm-test-01] => (item=scratch01) => { "msg": "scratch01: /dev/sdf before -> /dev/sdb after (vg_scratch/lv_scratch on /srv/scratch)" }
# (log01: sdd -> sde, data01: sdc -> sdd, backup01: sdb -> sdc)
PLAY RECAP *********************************************************************
vm-test-01 : ok=28 changed=2 unreachable=0 failed=0
Açılışta var01 diski sde'den sdf'ye kaydı; yeni eklenen scratch01 ise sdf iken açılışta sdb oldu. Diğer tüm komşular birer koltuk ötelendi.
Buna rağmen çalıştırma tamamen yeşil kaldı; çünkü yığındaki hiçbir şey bir harfi adreslemiyor: fstab /dev/vg/lv yollarını arıyor, LVM disklerin üzerindeki meta veriyi okuyor ve playbook'lar her çalıştırmada haritalamayı kernel görüşünden taze kuruyor. Recap yine ok=28 changed=2 kaldı; çünkü listeye beşinci bir girdi eklemek görev sayısını değil, döngü iterasyonlarını artırır: playbook makineyle birlikte büyüyor, hareketli parça sayısı ise hiç artmıyor.
Operasyonel Not: Kontrol düğümünde
df -h /srv/scratchçalıştırmak "No such file or directory" der; çünkü mount kontrol düğümünde değil, misafir makinededir. Doğrulama çıktısı SSH üzerinden misafirden okunmalıdır:
root@ctrl-01:~# ssh ubuntu@192.168.122.50 'df -h /srv/scratch'
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg_scratch-lv_scratch 5.0G 130M 4.9G 3% /srv/scratch
Depolama Katmanı Kapandı: Sırada Ne Var?
Depolama katmanı serinin taahhüt ettiği her iki boyutta da tamamlandı: golden template ve dört serial ile deklaratif olarak inşa edildi, tek bir tfvars düzenlemesiyle online büyütüldü ve bu addendum ile birlikte tek bir komutla reboot sınavından geçirildi.
Tek gerçek kaynaklı group_vars mimarisi, doğrulama playbook'u ve büyüme iş akışı sahada bizzat çalıştı. Alınan dersler; stat'ın sembolik bağları yalnızca açıkça istendiğinde takip ettiği, serial hotplug'ın şanslı bir günde online tamamlandığı ve upstream bir imajın pipeline ortasında kendini yenileyebileceği, gelecekteki çalıştırmaların bulacağı yerlere not edildi.
Her depolama değişikliğinden (büyütme ya da yeni disk ekleme) sonra operasyonel alışkanlık aynıdır:
- Önce kurulum playbook'unu çalıştır (
02_storage.yml), - Ardından doğrulama playbook'unu çalıştır (
03_storage_verify.yml).
İlki durumu yakınsar; ikincisi makinenin gece saat 3'te tek başına ayağa kalkabileceğini somut terminal çıktılarıyla kanıtlar.
Faz 2 tamamen kapandı. Sıradaki durak Faz 3:
- Template içindeki eski
/installdizinini gerçek Ansible rollerine dönüştürmek, - Mount noktalarına anlık denetim yerine kalıcı bir gözlemci atayacak Zabbix Agent 2,
- Merkezi güvenlik ajanları ve log diskini salt bir depolama alanından pipeline parçasına dönüştürecek QRadar rsyslog yönlendirme kuralları.
Top comments (0)