Bir bulut-uç (cloud-edge) süreklilik test ortamı kurulurken, etcd'nin yavaş depolama birimlerine karşı ne kadar hassas olduğu ortaya çıktı. MLSysOps adında, uygulamaların bulut, uç ve IoT ortamlarında dağıtım ve çalışma zamanı davranışlarını özelleştiren bir çerçeve için geliştirilen bir demoda, Karmada orkestratörünün pod'ları düzenli olarak çöküyordu. Bu durum, bir NUC üzerinde sanal makineler (VM) kullanarak oluşturulan dört düğümlü bir kümede yaşandı. NUC, hem Karmada ana bilgisayarı hem de k3s kümesinin kontrol düzlemi için birer VM barındırıyordu; Raspberry Pi ve Jetson AGX Orin ise işçi düğümleriydi.
Başlangıçta, kaynak limitleri, ağ yapılandırması gibi olağan şüpheliler kontrol edildi ancak sorun çözülemedi. Pod'lar her beş ila on dakikada bir yeniden başlatılıyor, bir süre çalışıyor ve tekrar çöküyordu. Kapsamlı bir hata ayıklama sürecinin ardından, sorunun etcd'nin disk performansı gereksinimlerinden kaynaklandığı anlaşıldı. etcd, dağıtılmış sistemlerde tutarlılığı sağlamak için kritik bir bileşen olup, özellikle yazma işlemleri için düşük gecikmeli ve yüksek verimli depolama birimlerine ihtiyaç duyar. Sanal makinelerin paylaşımlı disk kaynakları ve NUC'un depolama performansı, etcd'nin beklentilerini karşılayamadığı için istikrarsızlığa yol açtı.
Bu deneyim, dağıtılmış sistemlerde, özellikle etcd gibi hassas bileşenler kullanılırken, altta yatan donanım ve depolama performansının ne kadar kritik olduğunu gösterdi. Yavaş disk G/Ç (I/O) performansı, etcd'nin zaman aşımına uğramasına ve dolayısıyla pod'ların sürekli olarak çökmesine neden oldu. Bu durum, karmaşık sistemlerde hata ayıklama yaparken, en temel altyapı bileşenlerinin dahi göz ardı edilmemesi gerektiğini vurguluyor.
Dağıtılmış sistemlerde etcd'nin kararlı çalışması için disk G/Ç performansının kritik öneme sahip olduğu ve yavaş depolamanın beklenmedik sistem çöküşlerine yol açabileceği anlaşıldı.