Azure Storage Göçü: Planlamadan Kesime Sahadan Notlar
Şunu en başta söyleyeyim: kurumsal storage göçü, öyle “veriyi kopyaladık, bitti” diye geçiştirilecek bir iş değil. Terabaytlarla, bazen petabaytlarla uğraşıyorsanız, konu bir anda süreklilik, performans, maliyet ve — açık konuşayım — ekibin gece üçte telefona bakmadan uyuyabilmesi meselesine dönüyor.
İşin garibi, 20 küsur yıldır bu sektörün içindeyim. Hosting günlerinden bulut danışmanlığına kadar epey göç projesi gördüm; bazıları rahat aktı, bazıları işe ufak bir yanlış plan yüzünden günlerce uzadı. Şunu net söyleyebilirim: çoğu göç teknik sebepten değil, planlama eksikliğinden aksıyor; çünkü insanlar aracı seçmeden önce ne taşıdığını tam bilmiyor, sonra da şaşırıyorlar. Evet.
Tuhaf ama, Microsoft son dönemde Azure Migrate tarafına yeni bir katman ekledi: Azure Copilot Migration Agent. Bunu Azure Storage Mover ve Data Box gibi daha oturmuş araçların yanına koyunca ortaya fena olmayan, hatta bazı senaryolarda baya iş gören bir set çıkıyor (kendi tecrübem). Bugün bu seti kendi kafamdan geçirerek anlatacağım; yanı sadece “hangi araç ne yapar” kısmı değil, hangi durumda hangisini seçersiniz, Türkiye’deki şirket profiline nasıl oturur ve bütçe tarafında nerede durur, ona da bakacağız (bizzat test ettim). Bakın, peki neden?
Ve işler burada ilginçleşiyor.
Göç Planlamasının Aslında Nesi Zor?
Bir müşteri “storage’ımızı Azure’a taşıyalım” dediğinde ilk sorduğum şey şu oluyor: Ne kadar veriniz var, nerede dürüyor. Son 90 günde ne kadarına dokunuldu? Basit soru gibi dürüyor, değil mi? Ama işin aslı biraz ters; çoğu ekip bu üç soruya net cevap veremiyor, çünkü veri bir yerde değil, birkaç yerde dağınık hâlde yaşıyor.
Cevap alamıyorum. Genellikle. Hatta bazen yüzlerde o kısa sessizlik oluyor ya, işte o an tabloyu az çok anlıyorum. Daha açık söyleyeyim, peki neden? Çünkü envanter ayrı, kullanım ayrı, sahiplik ayrı; biri başka rapor veriyor, öbürü bambaşka konuşuyor, sonra sız oturup bunları birleştirmeye çalışıyorsunuz.
Sahada gördüğüm klasik tablo şu: NAS’ta 200 TB veri var deniyor, iş bitince 340 TB çıkıyor. Ya da tam tersi — 500 TB’lık file server’ın aslında 380 TB’ı 2019’dan beri açılmamış cold data. Şimdi bu iki durum için aynı stratejiyi mi kuracaksınız? Tabiî ki hayır. Ama planlama yoksa bunu önceden fark etmiyorsunuz; sonra herkes birbirine bakıyor, “hmm, bu kadar mıymış?” diye.
Evet, doğru duydunuz.
Fragmanlı planlama derdi burada başlıyor işte. Bir ekip PowerShell script’iyle envanter çıkarıyor, başka bir ekip üçüncü parti araçla bağımlılık analizi yapıyor, storage mimarı da elle Excel’e hedef mimarı çiziyor; güzel gibi dürüyor ama ortada tek ve güvenilir resim olmuyor. Neyse uzatmayayım, sonuç genelde aynı: kimse tam resmî göremiyor.
Göçün en pahalı kısmı taşıma değildir — yanlış hedef katmanı seçmektir. Cool tier’a gitmesi gereken veriyi Hot tier’a koyduğunuzda faturayı ilk ay değil, altıncı ayda görürsünüz. O zaman da geç kalınmış olur.
Azure Migrate: Merkezî Beyin
Azure Migrate’i biraz havuç gibi düşünün — her şeyin ortasında dürüyor, keşif de oradan dönüyor, değerlendirme de oradan geliyor, business case de orada şekilleniyor; bağımlılık analizi dahil pek çok şey tek noktadan görünür hâle geliyor. Sunucular, uygulamalar, veritabanları, storage… hepsi aynı ekranda toplanınca insan “tamamdır” diyor ama sonra bir bakıyor ki on-prem tarafı da var multi-cloud tarafı da var.
Bak şimdi, Ama açık konuşayım, Azure Migrate uzun süredir vardı ve storage tarafında biraz zayıf kalıyordu. Compute göçünde baya iş görüyor, dosya. Nesne verisi tarafında işe sizi kendi başınıza bırakıyordu; şimdi yeni Copilot Migration Agent tam bu boşluğu doldurmak için geldi diyebiliriz. Emin değilim ama sanırım asıl fark burada başlıyor.
Azure Copilot Migration Agent: Preview Ama İş Görüyor
Copilot Migration Agent şu an preview’da. Yanı üretim ortamına gözü kapalı sokulacak bir araç değil, açık konuşayım; ama POC tarafında baya iş görüyor. Ne yapıyor? Azure Migrate’in üstüne oturan bir AI katmanı gibi davranıyor, storage kaynaklarını tarıyor, veri özelliklerini çözümlüyor (dosya boyutu dağılımı, erişim sıklığı, tip falan), sonra da bunun hangi Azure servisine gitmesi gerektiğine dair öneri veriyor.
Evet, doğru duydunuz.
Kağıt üstünde idare eder gibi dürüyor. Pratikte işe… hmm, önerileri sorgulayın derim. AI’ın söylediği her şeyi doğru kabul edip geçmeyin. Bilhassa hibrit senaryolarda (mesela AD entegrasyonu olan SMB paylaşımları gibi) hâlâ insan gözü gerekiyor, çünkü bazen detaylar ilk bakışta temiz görünse de arkada küçük ama can sıkıcı istisnalar çıkabiliyor.
Bunun Türkiye Bağlamında Anlamı Ne?
Türkiye’deki kurumsal müşterilerin çoğu — özellikle finans, kamu, sağlık — hâlâ ciddi bir “on-prem konforu” içinde yaşıyor (ciddiyim). NetApp, Dell EMC Isilon, IBM Spectrum Scale gibi çözümlerle yıllardır çalışıyorlar; yanı işin aslı sadece teknik bir göç yok burada, aynı zamanda kültürel bir dönüşüm de var ve bu kısmı çoğu ekip ilk başta hafife alıyor.
Peki neden?
Copilot Migration Agent’ın burada faydası şu: teknik ekibin göçe direncini azaltıyor. Çünkü “sen ne dersen o” yerine “AI bak şunu öneriyor, biz de sebebini birlikte inceleyelim” diyebiliyorsunuz. Bu küçük fark bile karar sürecini hızlandırıyor; KVKK. Veri ikametgahı endişeleri olan kurumlarda işe üstüne bir de veri sınıflandırma çıktısı veriyor — hangi verinin nerede duracağına dair net olmayan noktaları biraz toparlıyor (kendi tecrübem)
Hangi Aracı Ne Zaman? Karar Matrisi
Şimdi işin asıl kısmına geldik. Elimizde dört ana araç var. Kafalar karışmasın diye ben bunu küçük bir tabloya döktüm, çünkü lafı uzatınca konu dağılıyor, biliyorsunuz.
| Araç | Ne İçin? | Ücret | İdeal Senaryo |
|---|---|---|---|
| Azure Migrate | Keşif + planlama | Ücretsiz | Her göçün başlangıç noktası |
| Copilot Migration Agent | AI destekli karar | Preview (ücretsiz) | Karmaşık storage ortamı, çok kaynak |
| Azure Storage Mover | Online senkron göç | Ücretsiz (yönetilen) | File/object, ağ bağlantısı iyi |
| Azure Data Box | Offline fiziksel transfer | Cihaz + kargo ücreti | PB ölçek veya zayıf bant genişliği |
Storage Mover: Sessiz Kahraman
Azure Storage Mover, açık konuşayım, listenin en az konuşulan ama baya iş gören aracı. Neden böyle öldü, tam emin değilim; Microsoft tarafı bunu biraz geri planda bırakmış gibi dürüyor. Mantıklı değil mi? Garip ama gerçek. Bu konuyla ilgili Work IQ Genel Kullanıma Açılıyor: Ajanlar İçin Zeka Katmanı yazımıza da göz atmanızı tavsiye ederim.
Mover’ın güzel tarafı şu: managed bir servis olarak geliyor. Sız gidip VM kurayım, DFS-R ayarlayayım, sonra da senkronu elle toparlayayım diye uğraşmıyorsunuz. Kaynakla hedef arasında bir agent mantığı var; bu agent çoğu zaman sıradan bir Linux VM üstünde çalışıyor, SMB ya da NFS’ten okuyor, blob’a veya Azure Files’a yazıyor ve işin sonunda delta senkronla son farkları taşıyor — yanı cutover anında saatlerce beklemek yerine son değişiklikleri alıp geçebiliyorsunuz. SkiaSharp 4.0 Kararlı Sürüm: .NET Grafiğinde Yeni Dönem yazımızda bu konuya da değinmiştik. Binlog MCP Server: CI’da Otomatik Build Analizi Devri yazımızda bu konuya da değinmiştik.
Ve işler burada ilginçleşiyor.
Şöyle söyleyeyim, Bu arada küçük bir not düşeyim — hatta önce bunu söylemek lazım — Storage Mover ücretsiz. Tabiî agent’ın koştuğu VM’in compute maliyeti. Network trafiği ayrı faturalanıyor, ama servisin kendisi için para ödemiyorsunuz. Türkiye’de bu önemli oluyor, çünkü bazı üçüncü parti göç araçları TB bazında lisans istiyor. 100 TB üstüne çıkınca rakamlar insanın moralini bozuyor.
Data Box: Fiziksel Kargo Nostaljisi
Bazen hesap kitap çok net oluyor. Diyelim elinizde 500 TB veri var. Internet çıkışınız 200 Mbps; bunu online taşımaya kalksanız teoride yaklaşık 230 gün sürüyor, pratikte işe 300 günü geçmesi hiç sürpriz değil. Evet, durum biraz tatsız.
İlginç olan şu ki, Data Box tam burada devreye giriyor. Microsoft size fiziksel bir cihaz gönderiyor (kapasitesine göre farklı modelleri var), sız veriyi buna kopyalıyorsunuz, sonra kargoyla geri yolluyorsunuz ve veri Azure tarafına yükleniyor. Kısacası eski usül sneakernet, ama iş görüyor.
Yanı, Türkiye tarafında ufak bir uyarı yapayım: Data Box’ın gönderim süreci. Gümrük işleri projeye 2-3 hafta ekleyebiliyor. Bunu baştan plana yazmazsanız sonradan tarih kaydırmak zorunda kalabiliyorsunuz; ben bunu birkaç müşteri işinde yaşadım, o yüzden boşuna demiyorum.
Gerçek Bir Senaryo: 180 TB File Server Göçü
İşin garibi, Hipotetik gibi dürüyor ama aslında sahaya baya yakın bir senaryo bu. Bir üretim şirketi düşünün; 180 TB SMB paylaşımı var, yaklaşık 40 milyon dosya dolaşıyor, Windows Server 2016 üstünde çalışıyor (ve evet, veri o kadar dağınık ki ilk bakışta insanın başını dönduruyor). Verinin yüzde 60’i son 2 yılda hiç acilmamis, yanı bildiğin cold tarafta bekliyor; yüzde 30’u aktif kullanılıyor, kalan yüzde 10 işe her gün el değiştiren sıcak veri.
İnanın, Klasik hata ne? Hepsini toptan Azure Files Premium’a atmak. Olur mu olur, ama faturayı görünce ekip — itiraz edebilirsiniz tabi — mudurunun yüz ifadesi değişir; hani bir anlık sessizlik olur ya, tam o an. Açık konuşayım, teknik olarak yapılabilir ama ekonomik olarak can yakar.
Doğru yol biraz daha karmaşık ama daha mantıklı giderdi: Bu konuyla ilgili WSL Container Public Preview: Windows’ta Linux Konteyner Devri yazımıza da göz atmanızı tavsiye ederim.
- Azure Migrate + Copilot Agent ile envanteri çıkar, veriyi sıcaklık kategorilerine ayır.
- Cold data -> Azure Blob Cool/Archive tier’a. Storage Mover ile aktarım yap.
- Aktif kullanimdaki veri -> Azure Files Standard (transaction optimized).
- Sıcak veri -> Azure Files Premium veya NetApp Files (performans ihtiyacına göre seç).
- Cutover öncesi 48 saat delta senkron çalıştır, sonra DNS/paylasim path yönlendirmesini değiştir. (bence en önemlisi)
Bence işin güzel tarafı burada çıkıyor. Bu yaklaşımla aylık storage faturası, her şeyi Premium’a taşımaya göre yüzde 60-70 daha düşük olabiliyor; rakamı Türk Lirasi bazında dusunurseniz, kur da oynuyorsa tabiî, yıllık fark iyice hissediliyor (ve CFO tarafında minik bir rahatlama oluyor). Evet, ciddi tasarruf.
Bağımlılık Analizi: Unutulan Adım
Eh, Peki neden proje en çok burada patlıyor? Çünkü file server’a bağlanan uygulamalar var ve bunlar genelde sessizce yaşıyor. Ne biliyorsunuz? SAP mi kullaniyorlar, (söylemesi ayıp) muhasebe sistemi mi var, yoksa üretim hattindaki bir SCADA yazılımı mi; bunların UNC path’lerini hardcoded tuttuğunu gorseydiniz gerçekten sasirdiniz. Bu tip detaylar ilk bakışta ufak görünüyor ama ispatlayinca büyük meseleye dönüşüyor.
Eğer bağımlılık analizini atlarsanız cutover gecesi sabaha karşı telefon çalar: “Üretim durdu, hiçbir dosyaya erisemiyoruz.” Buyrun size sabah mesaisi. Kötü kısım şu ki sorun bazen storage tarafında değil, eskiden kalma sabit path’lerde çıkıyor; yanı çözüm sandığınız yerden başka yerde patlatıyor olay. Claude Microsoft Foundry’de GA: Azure Faturasında Tek Satır yazımızda bu konuya da değinmiştik.
Azure Migrate’in bağımlılık analizi özelliği tam bu is için var aslında. Ama tek başına yetmiyor; uygulama sahipleriyle tek tek konusup hangi path’lerin nerede kullanıldığını doğrulamak lazım (inanın bana). Bu işi AI da yapamıyor — hâlâ insan işi. Mantıklı değil mi? Hani bazen araç iyi oluyor ama direksiyonu sız tutuyorsunuz ya, durum aynen o.
Startup vs Enterprise: Farklı Reçeteler
Küçük ya da orta ölçekli bir ekipseniz, mesela 5-10 kişilik bir ekip ve birkaç TB veri varsa, Copilot Migration Agent’a dalmanız şart değil. Doğrudan Storage Mover ile gidin. Hatta AzCopy bile iş görür. Overhead’e hiç girmeyin, açık konuşayım.
Evet.
Enterprise tarafında iş biraz değişiyor. 100+ TB, birden fazla lokasyon, üstüne bir de karmaşık AD entegrasyonu varsa, Azure Migrate’i planlama merkezî gibi kullanın; Copilot Agent’ı öneri almak için kenarda tutun, Storage Mover + Data Box hibrit yaklaşımı da baya mantıklı dürüyor (cold data’yı Data Box ile, delta’yı Storage Mover ile taşırsınız) (bizzat test ettim). Peki neden? Çünkü burada tek araçla her şeyi çözmeye çalışınca iş uzuyor.
Bir de üçüncü profil var: regülasyona tabi kurumlar yanı bankalar, kamu, sağlık. Burada göç sadece teknik bir mesele olmuyor; BDDK, KVKK, HIPAA gibi çerçevelere uyum da devreye giriyor. Bu gruptaysanız, göçten önce veri sınıflandırmasını yapın (Microsoft Purview burada iyi seçenek), destination tarafında da encryption-at-rest ve customer-managed keys mimarisini en baştan kurun. Sonradan eklemek can sıkıyor, hatta bazen projeyi gereksiz yere yavaşlatıyor.
Sık Yapılan Bir Hata ve Çözümü
Şunu hâlâ sık görüyorum: Cutover’ı hafta içi mesai saatinde yapmak. “Nasılsa senkron var” diye düşünen oluyor (evet, doğru duydunuz). Peki neden sorun çıkıyor? Çünkü final geçiş anında file lock’lar, açık handle’lar. O sırada yazılan veriler (in-flight write’lar) devreye giriyor, sonra da iş bir anda beklenmedik yere kayıyor.
Doğrusu şu: cutover’ı düşük trafik penceresinde yapın, yanı genelde Cuma akşamı 22:00 — Pazar 06:00 arası daha rahat oluyor, önden en az bir kere “dry run” yapın ve rollback planını da masanın üstüne koyun. Rollback derken sadece “geri döneriz herhalde” demek yetmiyor; adım adım hangi komutu çalıştıracağınız, hangi sırayla ilerleyeceğiniz, hatta kim neyi kontrol edecek, bunlar net olmalı.
Aslında, Ha bu arada, bu tip file paylaşımı göçlerinde Linux tarafı da işin içine girebiliyor. NFS senaryolarını biraz daha didik didik anlattığım başka bir yazım vardı: Azure Files NFS ile Linux İş Yükleri: Sahadan Notlar. Mesela POSIX permission haritalaması kısmında baya iş görüyor, hani bazı ortamda asıl takılma noktası orası oluyor ya, işte tam oraya dokunuyor.
Peki Sıra Modernizasyonda
Göç bitti diye is bitmiyor. Tam tersi. Asıl maraton yeni başlıyor, çünkü veriyi Azure’a tasidiniz, tamam, güzel. Sonra ne yapacaksınız, analitik mi kuracaksınız, AI mi deneyeceksiniz, yoksa uygulamayı da elden mi gecireceksiniz?
Şunu söyleyeyim, Storage stratejisini kurarken hedef mimariyi en baştan düşünmek lazım. Mesela veriyi ADLS Gen2 (belki yanılıyorum ama) formatında yerlestirdiyseniz, üstüne Synapse ya da Fabric ile analitik açabilirsiniz; ama Blob olarak attiysaniz ve niyet sadece arsivse, orada sorun yok gibi dürüyor. Fakat sonradan “hadi ML modeli egitelim” derseniz, is değişiyor, format dönüşümü de ek maliyet olarak karşınıza çıkıyor.
Şöyle ki, Data platformu tarafında son yaptığım işlerden biri Cosmos DB entegrasyonuydu; o konuya deginen bir yazım da var: Cosmos DB Built-in Connector for Logic Apps Standard GA Öldü — itiraf edeyim, beklentimin üstündeydi —. Storage göçü sonrası workflow otomasyonu düşünenlere fikir verebilir, hani bazen tek bir connector bütün akışı toparlıyor ya, tam o tarz bir senaryo.
Bunu biraz açayım.
Bir Örnek Storage Mover Komutu
Nasıl gorundugunu merak edenler için basit bir CLI örneği:
az storage-mover create \
--resource-group rg-migration \
--name sm-fileshare-prod \
--location westeurope
az storage-mover endpoint create-for-smb \
--storage-mover-name sm-fileshare-prod \
--resource-group rg-migration \
--name src-fileserver01 \
--host "fileserver01.corp.local" \
--share-name "SharedDocs"Bu tabiî sadece başlangıç. Job definition, credentials, agent registration derken adım adım ilerliyorsunuz; ilk bakışta biraz dağınık geliyor ama sonra oturuyor. Görüntü su: komut satırından yonetilebilen ve IaC (Bicep/Terraform) ile kaliplanabilen bir yapı var önünüzde.
Sıkça Sorulan Sorular
Azure Storage Mover ile AzCopy arasındaki fark ne?
AzCopy, hani tek seferlik kopyalama işleri için süper bir komut satırı aracı. Storage Mover işe yönetilen bir servis — senkronizasyon, delta transfer, job orchestration, monitöring gibi kurumsal özellikler sunuyor. Bence küçük taşımalarda AzCopy gayet yeterli, ama kurumsal. Süreklilik gerektiren işlerde Storage Mover çok daha mantıklı bir seçim.
Copilot Migration Agent preview’dayken güvenle kullanabilir mıyım?
Dürüst olmak gerekirse, Öneri ve analiz için evet, kullanabilirsin. Ama üretimde karar mekanizması olarak? Henüz değil (ciddiyim). Preview servisler SLA garantisi vermiyor ve API’ler değişebiliyor. Açıkçası, önce POC ortamında test et, kararlarını mutlaka insan gözüyle doğrula. GA olunca zaten tam entegrasyona rahatça geçebilirsin.
Data Box kullanırken verimin güvenliği nasıl sağlanıyor?
Cihaz AES 256-bit ile şifreleniyor, anahtar yönetimi TPM chip üzerinden yapılıyor. Fiziksel olarak da tamper-proof bir kasası var. Azure’a ulaştıktan sonra veri yükleniyor ve cihaz kriptografik olarak siliniyor — yanı NIST 800-88 standardına göre. Kargo süresince veri zaten okunamaz durumda kalıyor. Tecrübeme göre bu konuda ciddi anlamda sağlam bir süreç.
Petabayt ölçekte bir göçte online mı offline mı gitsem?
Vallahi, Aslında hesabı basit: veriyi mevcut bant genişliğine böl. Sonuç 30 günü geçiyorsa Data Box’a bak. Mesela 100 Mbps ile 1 PB taşımak yaklaşık 2.5 yıl sürüyor — Data Box Heavy ile aynı iş 2-3 haftaya iniyor. Ama delta senkronizasyon için Storage Mover’ı hibrit yaklaşımda tutmayı da düşün, bence o kombinasyon çoğu zaman en iyi sonucu veriyor.
Göç sırasında uygulamayı kesintisiz taşıyabilir mıyım?
File paylaşımları için Storage Mover’ın senkron modu ile kesintiyi dakikalara indirmek mümkün. Ama sıfır kesinti? Garanti değil. DNS TTL, client cache, açık handle’lar gibi faktörler devreye giriyor. Kritik uygulamalarda, açıkçası, hâlâ en güvenli yol “planlı bakım penceresi” yaklaşımı.
Kaynaklar ve İleri Okuma
Doğrusu, Azure Storage Mover Resmî Dokümantasyonu
Azure Data Box Ürün Ailesi Dokümantasyonu
Modernize your data with Azure Storage — Azure Blog
Yanı, Azure Migrate Services Overview
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder