HPE SimpliVity vaka çalışması: 20 saatlik yedeklemeden saniyelere

Bu yazı, Civil Mağazacılık’ın veri merkezini HPE SimpliVity hiper-bütünleşik altyapısına taşıdığı projenin vaka çalışmasıdır. Projede IT Müdürü olarak görev yaptım; HPE bu çalışmayı 2021’de Türkçe bir başarı hikâyesi olarak yayımladı. Aşağıdaki bütün rakamlar o belgeden alındı; yorumlar ve dersler ise bana ait.

Proje bağlamı: büyüyen bir perakendecinin altyapı sorunu

Civil Mağazacılık, 1996’da Civil Bebek ve Çocuk Dünyası olarak kuruldu. HPE belgesinin hazırlandığı dönemde şirket 70 yurt içi ve 10’dan fazla yurt dışı mağazası ile civilim.com e-ticaret sitesi üzerinden satış yapıyordu. 200 bin metrekarelik satış alanında, 3 binden fazla çalışanıyla her yıl 650’ye yakın markanın yaklaşık 42 bin çeşit ürününü sunuyordu.

Bu ölçekte bir perakendecide altyapı; mağaza kasaları, e-ticaret, lojistik, tedarik zinciri ve raporlama sistemlerinin aynı anda ayakta kalması demektir. Pandemi döneminde fiziksel mağaza ile dijital kanal arasındaki sınırın hızla silinmesi, altyapıdan beklentiyi daha da yükseltti. O dönem kendi ifademle şöyle anlatmıştım: “Perakende sektörü, salgın sürecinin de etkisiyle, teknolojiyle nefes alıp verdiği bir dönem yaşıyor.”

Önümüzdeki seçim netti. Eskiyen sunucu ve depolama donanımını parça parça yenilemek bir seçenekti. Ötekisi mimariyi değiştirmekti. Biz ikincisini seçtik.

Neden hiper-bütünleşik altyapı?

Geleneksel üç katmanlı veri merkezinde sunucular, ayrı bir depolama dizisi (SAN) ve bunları bağlayan depolama ağı bulunur. Her katmanın kendi yönetim arayüzü, kendi bakım sözleşmesi ve kendi darboğazı vardır. Hiper-bütünleşik altyapı (HCI) ise işlem gücünü, depolamayı ve sanallaştırmayı standart sunucu düğümlerinde, tek bir yazılım katmanı altında birleştirir.

Proje hedeflerimizi şöyle yazmıştık:

• Dijital erişilebilirlikte en iyi noktaya gelmek
• Kesintisiz ve güvenli bir altyapı
• Tek noktadan yönetim
• Esnek, performansı yüksek ve basit bir altyapı
• Verimli ve uygun maliyetli bir altyapı

SimpliVity’yi seçmemizin gerekçesi de bu listeye doğrudan karşılık geliyordu: kurumun kendi yapısını basitçe yönetebilmesi, yüzde 90’a varan kapasite tasarrufu vaadi, yerleşik veri koruması ve çok hızlı geri yükleme. Karar anındaki özetim şuydu: “HPE SimpliVity eskiyen ekipmanlara para dökmek yerine, daha verimli bir altyapıya daha uygun maliyetlerde ulaşmayı sağlıyor.”

Sonuçlar: rakamlarla proje

Ölçüt	Sonuç
Veri tekilleştirme	Ham depolamadaki tüm veri taşındığında 2,9:1
Sıkıştırma	Tekilleştirmeye ek olarak 1,5:1
Performans	Tekilleştirme sırasında performans kaybı yaşanmadı
Yedekleme süresi	Her gün 20 saati bulan süreler saniyelere indi
Yedek hacmi	Sürümlü olarak 1 petabaytın üzerinde
Kapasite yönetimi	%98,5 verimlilik

Bu tablodaki en değerli satır bence performans satırı. Tekilleştirme, kâğıt üzerinde her depolama ürününde bulunan bir özellik. Ama canlı bir sistemde, yoğun saatlerde, kullanıcı fark etmeden yapılabilmesi ayrı bir mesele. O dönem bunu “bir şirketin canlı sisteminde alabileceği en güzel sonuçlardan biri” diye tarif etmiştim ve bugün de aynı görüşteyim.

Tekilleştirme ve sıkıştırma nasıl çalışır?

Veri tekilleştirme (deduplication), depoya yazılan veriyi bloklara böler ve her bloğun parmak izini çıkarır. Aynı parmak izine sahip bir blok daha önce yazılmışsa ikinci kez yazılmaz, yalnızca ona bir işaretçi eklenir. Sanal sunucuların büyük bölümü aynı işletim sistemi dosyalarını taşıdığı için bu ortamlarda tekrar oranı yüksektir.

Sıkıştırma ise tekil kalan blokların kendi içindeki tekrarları küçültür. İkisi birbirinin alternatifi değil, tamamlayıcısıdır. Bizdeki sonuç da bu yüzden iki ayrı sayı olarak raporlandı: önce 2,9:1 tekilleştirme, üzerine 1,5:1 sıkıştırma.

Bir uyarı ekleyeyim. Bu oranlar veriye bağlıdır. Veritabanı yedekleri ve sanal makine kalıpları yüksek oran verir. Zaten sıkıştırılmış video, fotoğraf ya da şifreli dosyalar ise neredeyse hiç küçülmez. Satıcının broşüründeki oran sizin oranınız değildir; ölçmeden kapasite planı yapmayın.

Yedekleme penceresi: 20 saatten saniyelere

Projeden önce yedekleme süreleri her gün 20 saati buluyordu. Bu, pratikte günün neredeyse tamamında altyapının bir kısmının yedekle meşgul olması demekti. Bir işlem aksadığında ertesi günün yedeğiyle çakışma riski de hep vardı.

SimpliVity’de durum farklıydı, çünkü veri zaten yazılırken tekilleştirilip sıkıştırılıyordu. Yedek almak, verinin baştan sona yeniden okunup başka bir yere kopyalanması değil, o anki blokların meta verisini kaydetmekti. Verinin boyutu ne olursa olsun, terabaytlarca verinin yedeği saniyeler içinde alınabiliyordu.

Bunun doğal sonucu, yedeği daha sık ve daha çok sürümle tutabilmekti. Civil’de sürümlü yedeğin toplam hacmi 1 petabaytın üzerine çıktı. SimpliVity’nin burada sağladığı %98,5 verimlilik, kapasite yönetimini neredeyse kendiliğinden işleyen bir konuya dönüştürdü.

Projenin yönetimi: iş ortağı, bütçe ve hibrit geçiş

Projeyi HPE Türkiye ve iş ortağı Mayasoft ile yürüttük. Mayasoft ekibi, analiz sürecinde işi yalnızca bir donanım yenilemesi olarak görmedi; kurumun gelecek vizyonuyla orantılı bir çözüm tasarlamaya odaklandı. Kullanmaya devam edebileceğimiz mevcut kaynakların da hibrit bir mimaride projeye dahil edilmesi bu yaklaşımın sonucuydu.

Bütçe tarafında satın alma yerine HPE’nin kiralama (OPEX) modelini seçtik. Bu model, büyük bir sermaye harcamasını yıllara yayılan bir işletme giderine çevirerek bütçemize önemli katkı sağladı. Salgın dönemine rağmen ürünlerin hızla getirilmesi de projenin takvimini korudu.

HPE’nin belgesindeki kazanımlar listesi şu maddelerle bitiyordu: tüm sistemin tek noktadan yönetilmesi, hızlı yedekleme ve veri tekilleştirme, tek noktadan güvenlik ve veri analizi ile yapay zekâya hazır bir altyapı. Bu son madde o gün bir hedefti. Aynı yıl CX Teknoloji’yi kurup mevcut kameralarla gerçek zamanlı görüntü analitiği üzerine çalışmaya başladığımda, veriye hazır altyapının ne kadar belirleyici olduğunu bu kez diğer taraftan gördüm.

Bir BT yöneticisi olarak çıkardığım beş ders

1. Önce bugünü ölçün. “Yedekleme uzun sürüyor” bir şikâyettir, “yedekleme her gün 20 saat sürüyor” ise bir hedefin başlangıç noktasıdır. Proje başarısını anlatabilmemizin tek nedeni, başlamadan önceki durumu sayıyla bilmemizdi.

2. Yedeklemeyi değil, geri dönüşü test edin. Hızlı yedek güzel bir sonuçtur, ama asıl soru felakette sistemin ne kadar sürede ve ne kadar veri kaybıyla geri geldiğidir. Hedef kurtarma süresini (RTO) ve kabul edilebilir veri kaybını (RPO) yazılı hale getirin ve düzenli geri yükleme tatbikatı yapın.

3. Oranları kendi verinizle doğrulayın. Tekilleştirme ve sıkıştırma oranları veri tipine göre çok değişir. Kapasiteyi satıcının örneğine göre değil, kendi verinizle yapılan bir ön ölçüme göre planlayın.

4. Finansman modelini teknik kararın parçası sayın. CAPEX mi OPEX mi sorusu, en az hangi ürünün seçileceği kadar önemlidir. Doğru finansman modeli, doğru mimarinin kurum içinde onaylanmasını da kolaylaştırır.

5. Altyapıyı iş hedefine bağlayın. Bizim hedefimiz “yeni depolama almak” değil, fiziksel mağaza ile dijital kanalı kesintisiz destekleyen bir altyapıydı. Aynı yıllarda yürüttüğümüz Microsoft Azure geçişi ve SD-WAN projesi de aynı hedefin parçalarıydı.

Bugün aynı kararı nasıl verirdim?

2026’dan bakınca iki şeyi farklı vurgulardım. Birincisi fidye yazılımı. Bugün bir yedekleme mimarisinin ilk sorusu hızdan önce, yedeğin değiştirilemez (immutable) ve üretim ortamından yalıtılmış bir kopyasının olup olmadığıdır. İkincisi bulutla birlikte düşünmek. Hiper-bütünleşik altyapı ile genel bulut artık rakip değil; iş yükü nerede daha verimli çalışıyorsa orada çalışan hibrit bir mimarinin iki parçası.

Değişmeyen şey ise yöntem: ölç, iş hedefine bağla, kendi verinle doğrula, sonra karar ver. Bu ve benzer projelerin tamamını ödülleri ve kaynaklarıyla birlikte Başarılar sayfasında topladım.