Openstack test

Prompt

Sen production OpenStack/Ceph incident commander’sın. Ezbere genel tavsiye verme. Aşağıdaki ortamda gerçek zamanlı bir P1 incident yönetiyorsun. Yanıtın Türkçe olmalı; doğrudan uygulanabilir, copy-paste edilebilir komutlar içermeli. Tüm komutlarda değişkenleri açıkça belirt. Eksik bilgi varsa bunu varsayım olarak işaretle. Yıkıcı, veri kaybı veya downtime riski olan her komutun başına [DİKKAT] koy. "Restart et", "node'u reboot et", "container'a girip config değiştir" gibi yüzeysel çözümler kabul edilmez. # Kesin ortam bilgileri - OpenStack: Caracal 2024.1 - Deployment: Kolla-Ansible, Docker tabanlı containerized deployment - OS: Ubuntu 22.04 LTS compute node'ları, kernel 5.15 - Ceph: Squid 19.2+, cephadm ile yönetiliyor, Docker runtime - Cinder/Nova/Glance backend: External Ceph RBD - Neutron: OVN - HA: 3 controller, 8 compute, 6 Ceph OSD host - Masakari instance HA aktif - Nova shared instance storage: Hayır - Ephemeral disk: compute local disk üzerinde - Boot-from-volume instance'lar: Ceph RBD kullanıyor - Kolla servis logları: /var/log/kolla/<service>/ - Ceph log inceleme yöntemi: cephadm logs --name <daemon> - OpenStack container’larında manuel config değişikliği yasak - OpenStack config değişikliği gerekiyorsa sadece: 1. /etc/kolla/config/<service>/ altında override 2. kolla-ansible reconfigure -t <service> - Ceph için ceph-deploy, host-level systemd müdahalesi ve manuel daemon config yasak - Ceph komutları sadece cephadm shell veya merkezi yönetim hostundan çalıştırılabilir # Incident Saat 02:17’de compute-05 ile controller/storage network arasında asimetrik bir ağ arızası başladı. Belirtiler: 1. Controller node’ları compute-05’e SSH ile erişemiyor. 2. compute-05 üzerinde IPMI/iDRAC erişimi şu an yok. 3. compute-05’in management IP’si 10.10.20.55. 4. compute-05, Ceph public network’e ara sıra erişebiliyor gibi görünüyor: - ceph -s çıktısında OSD’ler sağlıklı. - Ancak bazı RBD client bağlantılarında timeout ve reset görülüyor. 5. compute-05 üzerindeki nova-compute heartbeat’i 70 saniye önce kesildi. 6. Nova service list çıktısı: +----+--------------+------------+----------+---------+-------+----------------------------+ | ID | Binary | Host | Zone | Status | State | Updated At | +----+--------------+------------+----------+---------+-------+----------------------------+ | 51 | nova-compute | compute-05 | nova | enabled | down | 2026-09-22T23:16:10.000000 | +----+--------------+------------+----------+---------+-------+----------------------------+ 7. Masakari compute-05 için recovery notification oluşturdu ve host’u maintenance durumuna almaya çalışıyor. 8. compute-05 üzerinde çalışan 12 instance var: - 9 adet boot-from-volume, root disk Cinder RBD - 3 adet local ephemeral root diskli instance - Bu 12 instance’tan 5 tanesi database cluster üyesi - 2 instance “NoValidHost” nedeniyle henüz başka compute’a taşınamadı 9. compute-05’de kalan QEMU süreçlerinin çalışıp çalışmadığı bilinmiyor. 10. Ceph tarafında aşağıdaki health detail görülüyor: HEALTH_WARN 1 clients failing to respond to capability release [WRN] CLIENT_CAPS: 1 clients failing to respond to capability release client.184392 failing to respond to capability release 11. `rbd status volumes/volume-<uuid>` çıktılarından biri compute-05 IP’sine işaret eden aktif watcher gösteriyor. 12. Masakari recovery workflow iki kez retry etti fakat evacuate tamamlanmadı. 13. Controller loglarında Nova API tarafında şu hata var: Compute service for host compute-05 is not forced down 14. Aynı anda Ceph monitor quorum sağlıklı, tüm OSD’ler up/in: - 6 mon quorum - 96 OSD up/in - PG state active+clean 15. Operasyon ekibi şunu istiyor: “En hızlı biçimde compute-05 üzerindeki boot-from-volume VM’leri ayağa kaldırın. Eğer mümkünse ephemeral VM’leri de kurtarın. Ancak evacuate edilen RBD disklerine eski compute-05’in tekrar yazması kesinlikle engellensin.” # Görev Aşağıdaki başlıklarla eksiksiz incident runbook üret: 1. İlk 5 dakika: - Hangi kontrolleri hangi sırayla yaparsın? - Hangi logları incelersin? - Her komutun amacı nedir? - Neden doğrudan nova force-down veya evacuate ile başlamazsın? 2. Kök neden hipotezleri: - Bu olayın network partition, nova-compute failure, Ceph client hang, RBD session sorunu veya control-plane sorunu olma ihtimallerini ayır. - Her hipotezi doğrulamak/elemek için somut komutlar ver. - Sadece `ceph -s` healthy görünmesinin neden güvenli fence kararı için yeterli olmadığını açıkla. 3. Güvenli fencing planı: - compute-05’i güvenli şekilde fence etmek için sıralı prosedür üret. - Ceph blocklist kullanımını açıkla. - Hangi IP/adresin blocklist’e alınacağını nasıl doğrularsın? - `10.10.20.55:0/0` blocklist yaklaşımının avantajını ve olası risklerini tartış. - Ceph blocklist doğrulanmadan hangi işlemler kesinlikle yapılmamalıdır? - QEMU kill, nova-compute force-down ve Masakari workflow sırasını gerekçelendir. - SSH erişilemezse hangi adımlar uygulanabilir, hangileri uygulanamaz? 4. Nova ve Masakari: - Nova’da compute service force-down nasıl uygulanır? - Masakari maintenance state ve notification/recovery durumları nasıl incelenir? - Evacuate’in neden başarısız olabileceğini, özellikle NoValidHost vakasını nasıl analiz edeceğini göster. - 9 boot-from-volume VM ile 3 ephemeral VM için ayrı kurtarma davranışlarını belirt. - Ephemeral instance’lar için “veri kurtarma” ve “instance availability” kavramlarını birbirinden ayır. 5. Ceph RBD veri bütünlüğü: - Eski hostta kalmış bir QEMU’nun aynı RBD’ye yazmasını önlemek için hangi kontroller gereklidir? - RBD watcher, blocklist ve stale client bağlantısı ilişkisini açıkla. - `client.184392 failing to respond to capability release` uyarısının olası anlamlarını değerlendir. - Blocklist ekledikten sonra hangi Ceph/Nova doğrulamalarını yaparsın? - Bir VM’nin yeni compute üzerinde güvenle başlatılabildiğini nasıl kanıtlarsın? 6. NoValidHost çözümü: - Scheduler filtreleri, Placement resource provider inventory/allocation, aggregate/AZ, trait, server group anti-affinity, flavor extra_specs, Cinder attachment ve Neutron port binding açısından teşhis akışı yaz. - Sadece gerekli kapasite yoksa “kapat/aç” önerme. - Problemi teşhis etmek için OpenStack CLI ve API loglarıyla kanıt tabanlı yöntem ver. - Kolla log path’lerini kullan; varsayılan olarak docker logs önerme. 7. Kontrollü unfence ve geri dönüş: - compute-05 daha sonra geri geldiğinde hangi güvenlik doğrulamaları yapılmadan blocklist kaldırılmamalıdır? - Eski hostta çalışan QEMU/virsh domain kontrolünü ver. - Host üzerinde ACTIVE instance kalıp kalmadığını nasıl kontrol edersin? - Nova service enable/up, Masakari maintenance kapatma ve scheduler’a geri alma sırası ne olmalı? - compute-05’in sadece health check geçince tekrar scheduling’e açılmasını sağlayacak bir acceptance checklist ver. 8. Otomasyon: - Bu olay için idempotent bir Bash pseudo-code veya gerçek Bash script iskeleti ver. - Script şu güvenlik özelliklerini içersin: - strict mode: set -euo pipefail - hostname allowlist/regex kontrolü - aynı host için flock ile paralel fencing engeli - Ceph blocklist başarıyla doğrulanmadan Nova force-down’a geçmeme - state file ile fenced host kaydı - dry-run desteği - retry ve açık loglama - Script içindeki yıkıcı adımları açıkça işaretle. 9. Son karar: - Bu olayda uygulanacak kesin operasyon sırasını en fazla 15 maddede özetle. - Her maddede “kanıt/validation” koşulu olsun. - Split-brain veya RBD veri bozulması riski varsa nerede durulması gerektiğini net biçimde belirt. # Değerlendirme kriterleri Cevabın aşağıdaki kriterlere göre değerlendirilecek: - Ceph blocklist uygulanmadan Nova force-down/evacuate yapılmasının riskini doğru açıklaması - Network partition ile gerçek host failure ayrımını doğru yapması - RBD watcher ve stale Ceph client davranışını doğru yorumlaması - Masakari, Nova force-down ve evacuate ilişkisini doğru açıklaması - Ephemeral instance kurtarma sınırlarını dürüstçe belirtmesi - NoValidHost için gerçek scheduler/Placement/Cinder/Neutron teşhis zinciri kurması - Kolla-Ansible ve cephadm operasyonel sınırlarına uyması - Yıkıcı işlem öncesi doğrulama, geri dönüş planı ve idempotency sağlaması - “Restart/reboot her şeyi çözer” gibi yüzeysel önerilerden kaçınması - Komutların production ortamda uygulanabilir olması