Bir Disk Kullanım Uyarısı Beni OpenStack Tavşan Deliğine Götürdü

Bir Disk Kullanım Uyarısı Beni OpenStack Tavşan Deliğine Götürdü

Bir sabah sunucularımızda beklenmedik bir disk kullanım uyarısı aldık. İlk başta basit bir disk temizliğiyle hallolacağını düşündüğümüz bu durum, bizi karmaşık ve derin bir yolculuğa çıkardı. Bu yolculuk, OpenStack’in iç işleyişini, özellikle de RabbitMQ’nun rolünü anlamamızı sağladı. Bu makalede, bu “tavşan deliğine” nasıl düştüğümüzü, neler öğrendiğimizi ve sizin de benzer durumlarda neler yapabileceğinizi adım adım anlatacağım. Amacımız, bu deneyimi bir ders niteliğinde sunarak, sizleri benzer sorunlarla karşılaştığınızda daha hazırlıklı hale getirmek.

Sorunun Kökenine İniş: Disk Alanı Tükeniyor!

Her şey, gece yarısı gelen bir e-posta ile başladı. Sistem izleme aracımız, kritik bir OpenStack düğümünde disk kullanımının %95’i aştığını bildiriyordu. Panik yoktu ama bir aciliyet hissi vardı. İlk tepki olarak, hızlı bir disk temizliği yapmaya karar verdik. Genellikle bu tür sorunlar, eski log dosyaları, geçici dosyalar veya gereksiz veritabanı yedekleri gibi basit nedenlerden kaynaklanır. Hızlıca ilgili dizinlere göz attık, büyük dosyaları tespit etmeye çalıştık ve bazı gereksiz görünen dosyaları sildik. Ancak, beklediğimiz rahatlama gelmedi. Disk kullanımı sadece birkaç puan düştü ve kısa süre sonra tekrar yükselmeye başladı. Bu durum, sorunun yüzeysel olmadığını, daha derinlemesine bir inceleme gerektirdiğini gösteriyordu. Sunucunun diskinde neyin bu kadar yer kapladığını anlamak için daha detaylı analizlere girişmek zorundaydık. Bu noktada, sorunun kaynağını belirlemek için sistemin genel işleyişini ve hangi servislerin en çok disk alanı tükettiğini anlamak kritik hale geldi.

Disk Alanı Analizi Nasıl Yapılır?

Disk kullanımını anlamak için ilk adım, hangi dizinlerin en çok yer kapladığını belirlemektir. Linux sistemlerinde bu iş için du (disk usage) komutu oldukça kullanışlıdır. Örneğin, mevcut dizindeki alt dizinlerin boyutlarını megabayt cinsinden görmek için şu komutu kullanabiliriz:

du -h -d 1

Bu komut, mevcut dizindeki her bir alt dizinin boyutunu insan tarafından okunabilir formatta (KB, MB, GB) gösterecektir. Eğer genel bir disk kullanımını görmek istiyorsak, kök dizinden başlayarak şu komutu kullanabiliriz:

sudo du -h --max-depth=1 /

Bu komut, kök dizindeki her bir üst seviye dizinin (örneğin, /var, /usr, /home) boyutunu listeleyecektir. Bu çıktıyı dikkatlice inceleyerek en çok yer kaplayan dizinleri tespit edebiliriz. Genellikle /var dizini, log dosyaları, geçici dosyalar ve veritabanları gibi dinamik verilerin saklandığı yer olduğu için disk alanı sorunlarının en sık yaşandığı yerdir. Özellikle /var/log dizini, sistem loglarının birikmesiyle hızla dolabilir.

Ayrıca, df -h komutu, dosya sistemlerinin genel kullanımını gösterir. Bu komut, hangi bölümün (partition) ne kadar dolu olduğunu ve hangi dosya sisteminin sorun yarattığını anlamak için önemlidir.

df -h

Bu çıktıda, Use% sütununu inceleyerek hangi bölümlerin kritik seviyede dolu olduğunu görebiliriz. Eğer bir bölümün kullanım oranı %90’ın üzerindeyse, o bölümdeki disk kullanımını daha detaylı araştırmalıyız. Bu ilk analiz adımları, sorunun nerede yoğunlaştığına dair bize önemli ipuçları verecektir.

OpenStack ve Mesajlaşma Kuyrukları: RabbitMQ Devreye Giriyor

Detaylı analizler sonucunda, diskte en çok yer kaplayan alanın /var/lib/rabbitmq/mnesia/rabbit@hostname/msg_store/vhosts/default/queues dizini olduğunu fark ettik. Bu dizin, RabbitMQ mesajlaşma kuyruklarının depolandığı yerdi. Açıkçası, bu dizinin bu kadar büyük boyutlara ulaşması bizi şaşırttı. RabbitMQ, OpenStack bileşenleri arasında iletişimi sağlayan kritik bir mesajlaşma kuyruğu (message queue) sistemidir. Nova (compute), Neutron (networking), Cinder (block storage) gibi servisler, birbirleriyle haberleşmek için RabbitMQ’yu kullanırlar. Dolayısıyla, RabbitMQ’da yaşanan bir sorun, tüm OpenStack kümesini etkileyebilir.

Ancak, neden bu kuyrukların bu kadar çok veriyle dolduğunu anlamak gerekiyordu. Normalde, mesajlar işlendikten sonra kuyruktan silinir. Eğer mesajlar işlenemiyor veya kuyruktan silinmiyorsa, zamanla birikir ve disk alanını tüketir. Bu durumun birkaç olası nedeni olabilir:

• Hizmet Kesintisi: Mesajları işleyen OpenStack servislerinden biri veya birkaçı çalışmıyor olabilir. Bu durumda, mesajlar kuyrukta bekler ve işlenemez.
• Hata Döngüsü: Mesajların işlenmesinde sürekli bir hata oluşuyor olabilir. Bu, mesajların tekrar tekrar denenmesine ama hiçbir zaman başarılı olmamasına yol açar.
• Konfigürasyon Sorunları: RabbitMQ veya OpenStack servislerinin konfigürasyonunda yanlışlıklar olabilir. Örneğin, mesajların silinme politikaları yanlış ayarlanmış olabilir.
• Aşırı Yüklenme: Sistem, gelen mesajları işleyebileceğinden daha hızlı bir şekilde almaya başlamış olabilir.

Bu noktada, sorunun kaynağını daha net anlamak için RabbitMQ’nun yönetim arayüzüne ve ilgili OpenStack servislerinin loglarına bakmamız gerekiyordu. Bu, bize hangi mesajların takıldığını ve hangi servislerin sorun çıkardığını gösterecekti. Bu tür bir durumla ilk kez karşılaşanlar için, RabbitMQ’nun temel çalışma prensiplerini ve OpenStack içindeki yerini anlamak, sorunun çözümünde kritik öneme sahiptir.

RabbitMQ Temelleri ve OpenStack Entegrasyonu

RabbitMQ, AMQP (Advanced Message Queuing Protocol) gibi standartları destekleyen açık kaynaklı bir mesaj aracısıdır (message broker). Temel olarak, mesajların gönderildiği (publisher) ve alındığı (consumer) bir sistemdir.

• Exchange: Mesajların geldiği ilk noktadır. Mesajları belirli kurallara göre kuyruklara yönlendirir.
• Queue: Mesajların depolandığı yerdir. Consumer’lar bu kuyruklardan mesajları alıp işler.
• Binding: Exchange ile Queue arasındaki bağlantıdır. Hangi Exchange’in hangi Queue’ya mesaj göndereceğini belirler.
• Publisher: Mesajları üreten ve Exchange’e gönderen uygulamadır.
• Consumer: Queue’dan mesajları alan ve işleyen uygulamadır.

OpenStack’te RabbitMQ, servisler arası asenkron iletişimi sağlamak için kullanılır. Örneğin, bir kullanıcı bir sanal makine oluşturma isteği gönderdiğinde, Nova API’si bu isteği bir mesaja dönüştürür ve RabbitMQ’ya gönderir. Ardından, Nova Compute servisi bu mesajı RabbitMQ’dan alır ve sanal makineyi oluşturma işlemini başlatır. Bu asenkron yapı, sistemin daha ölçeklenebilir ve hata toleranslı olmasını sağlar. Ancak, bu iletişimin sağlıklı işlemesi, hem RabbitMQ’nun kendisinin hem de mesajları işleyen OpenStack servislerinin düzgün çalışmasına bağlıdır.

RabbitMQ Yönetim Arayüzü ve Sorun Giderme

Disk kullanımının ana kaynağını belirledikten sonra, bir sonraki adımımız RabbitMQ yönetim arayüzüne (management plugin) erişmek oldu. RabbitMQ, varsayılan olarak bir web tabanlı yönetim arayüzü sunar. Bu arayüz, kuyrukları, bağlantıları, kanalları ve kullanıcıları izlemek için harika bir araçtır. Yönetim arayüzüne giriş yaptıktan sonra, “Queues” sekmesine giderek mevcut tüm kuyrukları görebiliriz. Burada, kuyrukların mesaj sayılarını, tüketilen mesaj sayılarını ve diğer istatistikleri inceleyebiliriz.

Bizim durumumuzda, belirli kuyruklarda (özellikle openstack.ha.ha_policy_quorum ile ilgili olanlar) çok sayıda bekleyen mesaj olduğunu gördük. Bu, bu mesajların bir şekilde işlenemediğini gösteriyordu. Ardından, “Exchanges” sekmesine göz attık ve “Consumers” sekmesini inceleyerek hangi servislerin mesajları tükettiğini anlamaya çalıştık. Bu incelemeler sırasında, bazı OpenStack servislerinin (örneğin, nova-scheduler, neutron-l3-agent) beklenmedik bir şekilde durduğunu veya hata verdiğini fark ettik. Bu servislerin loglarını incelediğimizde, genellikle bir hata veya zaman aşımı (timeout) nedeniyle mesajları işleyemediklerini gördük. Bu, sorunun kaynağını artık daha net bir şekilde ortaya koyuyordu: OpenStack servislerindeki bir sorun, mesajların RabbitMQ’da birikmesine neden oluyordu.

Bu noktada, sorunu çözmek için sadece RabbitMQ’yu temizlemek yeterli olmayacaktı. Asıl yapılması gereken, bu mesajların birikmesine neden olan OpenStack servisindeki sorunu bulup düzeltmekti. Bu, genellikle ilgili servislerin loglarını derinlemesine incelemeyi, konfigürasyon dosyalarını kontrol etmeyi ve hatta gerekirse servisleri yeniden başlatmayı gerektirir.

RabbitMQ’da Bekleyen Mesajları Temizleme Yöntemleri

Eğer gerçekten de disk alanı sorununa neden olan birikmiş mesajlar varsa ve sorunun kaynağı olan servis düzeltilene kadar geçici bir çözüm gerekiyorsa, kuyrukları temizlemek bir seçenek olabilir. Ancak bu, veri kaybına yol açabileceği için dikkatli yapılmalıdır.

Yönetim arayüzünden kuyrukları tek tek temizlemek mümkündür. Bunun için ilgili kuyruğun üzerine tıklayıp “Purge” (Temizle) düğmesine basılır. Ancak, çok sayıda kuyruk varsa bu pratik değildir.

Daha programatik bir yaklaşım için, RabbitMQ’nun CLI aracını veya API’sini kullanabiliriz. Örneğin, bir kuyruğu temizlemek için rabbitmqadmin komutunu kullanabiliriz:

rabbitmqadmin purge queue name=kuyruk_adi

Bu komut, belirtilen kuyruk_adi‘ndaki tüm mesajları siler. Ancak, bu komutu çalıştırmadan önce hangi kuyrukları temizleyeceğinizden emin olmalısınız. Hangi kuyrukların sorun yarattığını belirlemek için yönetim arayüzündeki istatistiklere bakmak önemlidir. Unutmayın, bu sadece geçici bir çözümdür ve asıl sorunu çözmek için ilgili OpenStack servisindeki hatayı gidermeniz gerekir.

Gerçek Dünya Senaryosu: Bir Cinder Sorunu ve RabbitMQ’nun Etkisi

Bir zamanlar, bir müşterimizin OpenStack bulutunda beklenmedik bir şekilde disk alanı tükenmesi sorunuyla karşılaştık. Yapılan incelemeler sonucunda, sorunun cinder-volume servisinden kaynaklandığı ortaya çıktı. Müşterimiz, yeni sanal makineler oluştururken veya mevcut sanal makinelere yeni diskler eklerken sürekli olarak hatalar alıyordu. Disk kullanım analizi yaptığımızda, /var/lib/rabbitmq dizininin olağan dışı bir şekilde büyüdüğünü gördük.

RabbitMQ yönetim arayüzünü incelediğimizde, özellikle Cinder ile ilgili kuyruklarda (örneğin, cinder.volume, cinder.scheduler) milyonlarca bekleyen mesaj olduğunu fark ettik. Bu mesajlar, Cinder’ın diskleri sağlaması, eklemesi veya silmesi gibi işlemleri temsil ediyordu. Ancak, cinder-volume servisinin loglarını incelediğimizde, diskleri bağlama (attaching) veya ayırma (detaching) işlemleri sırasında sürekli olarak I/O hataları aldığını gördük. Bu hataların nedeni ise, depolama sistemindeki (örneğin, Ceph veya SAN) bir bağlantı sorunu veya yapılandırma hatasıydı.

Sonuç olarak, cinder-volume servisi, disk işlemleri için gönderilen mesajları işleyemiyordu. Bu mesajlar RabbitMQ’da birikerek devasa boyutlara ulaştı ve nihayetinde disk alanını tüketti. Sorunu çözmek için öncelikle depolama sistemindeki bağlantı sorununu giderdik. Ardından, cinder-volume servisinin loglarını temizleyip servisi yeniden başlattık. Bu işlemden sonra, RabbitMQ’daki kuyruklar hızla boşaldı ve disk kullanımımız normale döndü. Bu vaka analizi, OpenStack’in farklı bileşenlerinin birbirine ne kadar sıkı bağlı olduğunu ve bir bileşendeki küçük bir sorunun bile tüm sistemi nasıl etkileyebileceğini açıkça gösterdi. Özellikle mesajlaşma sistemleri, bu tür zincirleme reaksiyonların merkezi haline gelebilir.

OpenStack’te Disk Kullanımını Önleyici Tedbirler

Bu tür disk doluluğu sorunlarıyla karşılaşmamak için proaktif önlemler almak her zaman en iyisidir. OpenStack gibi karmaşık sistemlerde, düzenli bakım ve izleme, sorunlar büyümeden tespit edilip çözülmesini sağlar. İşte alabileceğiniz bazı önlemler:

• Düzenli Log Temizliği: /var/log dizinindeki log dosyalarının düzenli olarak temizlenmesini sağlayın. Logrotate gibi araçlar bu konuda çok yardımcı olabilir.
• Disk Kullanımını İzleme: Sunucularınızın disk kullanımını düzenli olarak izleyin. %80 kullanım seviyesine ulaşıldığında uyarı verecek şekilde izleme araçları kurun.
• RabbitMQ Mesajlarını İzleme: RabbitMQ yönetim arayüzünü kullanarak kuyruklardaki mesaj sayılarını düzenli olarak kontrol edin. Beklenmedik bir artış, bir sorunun habercisi olabilir.
• OpenStack Servis Loglarını İnceleme: OpenStack servislerinin (Nova, Neutron, Cinder, Keystone vb.) loglarını düzenli olarak inceleyerek olası hataları erken tespit edin.
• Kapasite Planlaması: Sisteminizi sürekli olarak izleyerek ve gelecekteki ihtiyaçları tahmin ederek disk alanı kapasitesini yeterli tutun.
• Otomatik Temizleme Scriptleri: Eski geçici dosyaları, eski snapshot’ları veya gereksiz veritabanı kayıtlarını temizlemek için otomatik scriptler oluşturun.
• RabbitMQ Konfigürasyonu: RabbitMQ’nun mesajların yaşam süresi (TTL – Time To Live) ve kuyruk başı limitleri gibi konfigürasyonlarını optimize ederek mesajların gereksiz yere sonsuza dek kalmasını engelleyin.

Bu önlemler, sadece disk alanı sorunlarını değil, aynı zamanda genel sistem kararlılığını da artıracaktır. Unutmayın ki, bulut altyapılarında proaktif bakım, reaktif müdahaleden her zaman daha ekonomiktir.

İleri Düzey: RabbitMQ Performans Ayarları ve OpenStack Entegrasyonu

Daha büyük ve yoğun OpenStack ortamlarında, sadece disk alanı sorunlarını gidermekle kalmayıp, RabbitMQ’nun performansını optimize etmek de önemlidir. RabbitMQ’nun performansını etkileyen birçok faktör vardır. Bunlardan bazıları şunlardır:

• Disk I/O Performansı: RabbitMQ, mesajları diske yazıp okuduğu için disk I/O performansı kritiktir. SSD’ler kullanmak, I/O performansını önemli ölçüde artırabilir.
• Bellek Kullanımı: RabbitMQ, mesajları önbelleğe almak için belleği kullanır. Yeterli belleğe sahip olmak, performansı olumlu etkiler.
• Ağ Gecikmesi: Publisher ve Consumer’lar ile RabbitMQ arasındaki ağ gecikmesi, mesaj işleme süresini etkiler. Düşük gecikmeli ve yüksek bant genişlikli ağlar tercih edilmelidir.
• RabbitMQ Konfigürasyonu: rabbitmq.conf dosyasındaki ayarlar, performansı doğrudan etkiler. Örneğin, vm_memory_high_watermark gibi ayarlar, belleğin ne kadar kullanılacağını belirler.
• OpenStack Servis Konfigürasyonu: OpenStack servislerinin (örneğin, Nova, Neutron) RabbitMQ ile nasıl etkileşimde bulunduğu da performansı etkiler. Publisher confirm’leri kullanmak, mesajların başarıyla iletildiğinden emin olmanızı sağlar.

Ayrıca, yüksek kullanılabilirlik (High Availability – HA) için RabbitMQ kümelemesi (clustering) ve OpenStack’in HA politikalarıyla entegrasyonu da önemlidir. OpenStack’in HA politikaları, mesajların birden fazla RabbitMQ düğümünde çoğaltılmasını sağlayarak veri kaybını önler ve sistemin daha dayanıklı olmasını sağlar. Ancak, HA yapılandırmaları da ek kaynak gerektirir ve doğru şekilde yönetilmelidir. Bu tür ileri düzey ayarlar, özellikle büyük ölçekli ve kritik OpenStack ortamlarında sistem kararlılığını ve performansını maksimize etmek için gereklidir. Bu ayarların her biri, sistemin genel işleyişini ve kaynak kullanımını doğrudan etkiler.

Sonuç: Tavşan Deliğinden Çıkış ve Öğrenilen Dersler

Başlangıçta basit bir disk kullanım uyarısı olarak görünen sorun, bizi OpenStack’in karmaşık mesajlaşma altyapısına, yani RabbitMQ’nun derinliklerine kadar götürdü. Bu yolculuk boyunca, disk alanı sorunlarının sadece yüzeysel temizlikle çözülemeyeceğini, altta yatan nedenlerin araştırılması gerektiğini öğrendik. RabbitMQ’nun OpenStack içindeki kritik rolünü, mesajların nasıl biriktiğini ve bu birikimin neden olabileceği sorunları yakından gördük. Gerçek dünya senaryoları ve vaka analizleri, bu tür sorunların sadece teorik olmadığını, canlı sistemlerde de sıkça karşılaşılabildiğini gösterdi.

En önemli derslerimizden biri, sistemlerin birbirine ne kadar sıkı bağlı olduğuydu. Bir OpenStack bileşenindeki küçük bir hata, mesajlaşma kuyruğunda birikerek tüm altyapıyı etkileyebilirdi. Bu deneyim, düzenli izleme, proaktif bakım ve derinlemesine sorun giderme yeteneklerinin ne kadar hayati olduğunu bir kez daha kanıtladı. Artık, bir disk kullanım uyarısı aldığımızda, ilk olarak en olası nedenleri (loglar, geçici dosyalar) kontrol etsek de, doğrudan OpenStack’in mesajlaşma katmanına ve ilgili servislerin durumuna bakmayı da ihmal etmiyoruz. Bu, sorunları daha hızlı teşhis etmemizi ve çözmemizi sağlıyor.

Umarım bu makale, sizleri de benzer “tavşan deliklerine” düşerseniz daha hazırlıklı hale getirir. Unutmayın, her sorun, yeni bir şeyler öğrenmek için bir fırsattır.

Sıkça Sorulan Sorular (SSS)

1. RabbitMQ neden disk alanı tüketir?
   RabbitMQ, mesajları işlenene kadar kuyruklarda depolar. Eğer mesajları işleyen servislerde bir sorun varsa (çalışmıyorsa, hata veriyorsa veya aşırı yüklenmişse), mesajlar kuyruklarda birikir ve zamanla disk alanını tüketir.
2. OpenStack’te disk alanı sorunlarını önlemek için neler yapmalıyım?
   Düzenli log temizliği, disk kullanımını izleme, RabbitMQ kuyruklarını kontrol etme, OpenStack servis loglarını inceleme ve yeterli kapasite planlaması gibi önlemler almalısınız.
3. RabbitMQ yönetim arayüzüne nasıl erişebilirim?
   Genellikle RabbitMQ sunucusunun çalıştığı IP adresi ve yönetim eklentisinin çalıştığı port (varsayılan olarak 15672) ile erişilir. Örneğin: http://sunucu_ip_adresi:15672. Varsayılan kullanıcı adı ve şifresi genellikle guest/guest‘tir ancak güvenlik nedeniyle bu değiştirilmelidir.
4. RabbitMQ’daki kuyrukları temizlemek veri kaybına yol açar mı?
   Evet, kuyrukları temizlemek, içinde bulunan tüm mesajları kalıcı olarak siler. Bu nedenle, bu işlemi yalnızca sorunun kaynağını anladığınızdan ve bu mesajların artık gerekli olmadığından emin olduğunuzda yapmalısınız.
5. OpenStack’te RabbitMQ HA (Yüksek Kullanılabilirlik) nedir ve neden önemlidir?
   RabbitMQ HA, mesajların birden fazla RabbitMQ düğümünde çoğaltılarak veri kaybını önlemeyi ve sistemin kesintisiz çalışmasını sağlamayı amaçlar. OpenStack gibi kritik altyapılarda, servislerin sürekli erişilebilir olması için HA önemlidir.

#OpenStack #RabbitMQ #BulutBilişim #SistemYönetimi #TeknikMakale