Azure'dan Kiralık Sunucuya Geçiş: AD, Dosya ve VPN

Azure'dan kurumsal sunucu kiralamaya geçiş, her uygulamayı buluttan çıkarmak anlamına gelmez. Bir işletme Azure sanal makinelerinde çalışan Active Directory Domain Services (AD DS), dosya sunucusu veya belirli uygulama iş yüklerini farklı bir veri merkezi altyapısına taşırken Microsoft 365, Teams, Exchange Online ve SharePoint Online hizmetlerini kullanmaya devam edebilir. Doğru karar, yalnız aylık fatura karşılaştırmasıyla değil; ağ erişimi, kimlik eşitlemesi, uygulama bağımlılıkları, veri taşıma ve kurtarma hedefleriyle verilmelidir.

Kısa cevap: Önce Azure ortamındaki sunucu ve servisleri envanterleyin. AD, DNS ve kimlik eşitlemesinin birbirine nasıl bağlandığını doğrulayın. Hedef kurumsal sunucu kiralama altyapısında yeni servisleri hazırlayın; VPN bağlantısını ve yedekleri doğrulayın. Dosya sunucusunun izinlerini koruyarak geçişi test edin, kullanıcı erişimini kontrol edin ve eski Azure kaynaklarını ancak geri dönüş penceresi tamamlandıktan sonra kapatın. Teklif hazırlatmak için Azure'dan sunucu taşıma ihtiyacınızı iletin.

Bu rehber, Azure VM giderlerini gözden geçirmek isteyen BT yöneticilerine, çok şubeli kurumlara ve muhasebe/ERP uygulamalarını yöneten işletmelere yöneliktir. Her bulut hizmetini kapatmak yerine hangi iş yükünün hangi ortamda kalacağını teknik ve finansal gerekçeyle belirlemeye odaklanır.

1. Azure'dan kiralık sunucuya geçiş ne zaman değerlendirilmeli?

Azure üzerinde sürekli çalışan belirli sanal makineler için maliyet tahminleri yapılırken işlemci, RAM ve disk kapasitesinin yanında yedekleme, trafik, güvenlik ve operasyon kalemleri de görülmelidir. Ancak Azure'daki hizmetlerin tamamı aynı kullanım modeline sahip değildir. Dönemsel veya kolay ölçeklenmesi gereken uygulamalar bulutta avantajlı olabilirken sürekli çalışan bazı altyapı sunucuları için ayrılmış kaynakların teklifini karşılaştırmak anlamlı olabilir.

Örneğin bir firmanın Azure VM üzerinde tek etki alanı denetleyicisi, dosya sunucusu ve Windows uygulama sunucusu çalıştırdığını düşünelim. Bu temsili senaryoda Microsoft 365 abonelikleri mevcut haliyle devam ederken AD DS ve dosya hizmetleri bir kiralık sunucu veya özel bulut ortamına taşınabilir. Fakat kurumun şubeleri, internet hatları, uygulama lisansları ve güvenlik politikası değerlendirilmeden geçişin daha ucuz veya daha hızlı olacağı söylenemez.

İş yüklerini seçerken özel bulut ve hibrit altyapı çözümleri ile tamamen bulutta kalma seçeneklerini aynı teknik ihtiyaç listesi üzerinden karşılaştırmak gerekir.

2. Hangi Azure servisleri taşınır, hangileri bulutta kalır?

Azure VM, Microsoft Entra ID ve Microsoft 365 farklı hizmet katmanlarıdır. Bir VM içindeki Windows Server AD DS etki alanı denetleyicisini taşımak, buluttaki Entra ID dizinini otomatik taşımaz. Aynı şekilde Microsoft 365 posta kutuları ve Teams içerikleri, yalnız dosya sunucusu yeni lokasyona geçti diye yeni sunucuya taşınmış olmaz.

Bu tablo bir proje teklifi veya zorunlu mimari değildir. Özellikle Azure Files, Azure SQL veya diğer yönetilen servislerin taşınabilirliği, VM üzerindeki geleneksel iş yüklerinden farklıdır.

3. Active Directory sunucusu güvenli biçimde nasıl taşınır?

Domain Controller'ı sıradan bir dosya sunucusu gibi kopyalayıp üretimde açmak, doğru varsayılan geçiş yöntemi değildir. Mevcut etki alanının sağlığı, domain/forest seviyesi, DNS, replikasyon, Global Catalog ve operasyon master (FSMO) rolleri önceden kontrol edilmelidir.

Yaygın planlardan biri; hedef lokasyonda etki alanına uygun yeni bir Windows Server hazırlamak, güvenli ağ bağlantısıyla domain'e dahil etmek, ek Domain Controller olarak yapılandırmak ve replikasyon sağlığını doğrulamaktır. Gerekli durumlarda FSMO rolleri kontrollü transferle yeni sahibine alınır; eski DC ancak servis bağımlılıkları ve geri dönüş planı değerlendirildikten sonra demote edilir. Microsoft'un FSMO rolleri aktarma dokümanı normal rol transferi ve koşullarını açıklar.

İnce nokta: DNS sunucusu ve istemcilerdeki DNS adresleri güncel değilse kullanıcılar yeni DC sağlıklı olsa bile oturum açma veya isim çözümleme sorunları yaşayabilir. Şubeler ve VPN kullanıcıları açısından AD erişimini ayrıca test edin. Active Directory ve dosya hizmetleri çözümlerini bu nedenle ayrı iş paketi olarak ele almak önemlidir.

4. Microsoft 365 ve Microsoft Entra kimlik eşitlemesi devam eder mi?

Devam edebilir; ancak doğru yapılandırma gerekir. On-premises AD DS kullanıcılarının Microsoft Entra ID ile eşitlenmesi için kullanılan Microsoft Entra Connect Sync veya Microsoft Entra Cloud Sync tasarımının hangi sunucuda çalıştığı bilinmelidir. Eşitleme sunucusu Azure VM üzerindeyse ve taşınacaksa, yalnız domain controller'ı taşımak yeterli değildir.

Eşitlemenin mevcut durumu, kullanılan özellikler, servis hesabı, ağ/proxy erişimi, desteklenen Windows Server sürümü, geri dönüş ve mümkünse staging/alternatif ajan yaklaşımı değerlendirilmelidir. Microsoft'un hibrit kimlik başlangıç rehberi ile Entra Cloud Sync önkoşulları ürünlerin gereksinimlerini açıklar.

Microsoft 365 kalacak, AD başka veri merkezinde çalışacak tasarımında kullanıcı oturumu, parola eşitleme, uygulama bağımlılıkları ve geçiş süresince yönetici erişimi ayrı test senaryolarıdır. Şirket içi Windows AD ile bulut kimliğinin aynı ürün olmadığını unutmamak, hatalı taşıma kararlarını azaltır.

5. File Server taşırken NTFS izinleri nasıl korunur?

Dosya sunucusunda kritik konu yalnız toplam GB veya TB miktarı değildir. NTFS izinleri, SMB paylaşım tanımları, sahiplik, klasör mirası, açık dosyalar, kullanıcı grupları ve uygulamaların kullandığı UNC yolları birlikte envanterlenmelidir.

Microsoft'un Storage Migration Service altyapısı, desteklenen senaryolarda sunucu envanteri, dosya/paylaşım ve güvenlik yapılandırması aktarımı ile uygun durumlarda kesintiyi azaltan cutover adımlarına yardımcı olabilir. Bunun kullanılabilirliği kaynak ve hedef platforma, kimlik planına ve ağ koşullarına bağlıdır.

Dosya kopyalamada kullanılan yöntemin yalnız içeriği değil ACL, zaman damgası ve sahipliği gereken kapsamda koruduğunu test edin. Ağ paylaşım izinleri ile NTFS izinleri aynı şey olmadığından yetkili, yetkisiz ve salt okunur kullanıcı testleri yapın. Eski paylaşımlardaki dosya yolu bağımlılıkları da uygulama tarafında doğrulanmalıdır.

6. Azure ve veri merkezi arasında IPsec VPN nasıl planlanır?

Taşıma sırasında kaynak ve hedef ortamların bir süre birlikte çalışması gerekebilir. Bu durumda güvenli yönlendirme, DNS çözümleme ve uygun site-to-site IPsec VPN veya alternatif özel bağlantı planı, AD replikasyonu ve veri transferi için önem kazanır.

Teklifte kaynak/hedef IP adres planları, olası adres çakışmaları, kullanılacak ağ protokolleri, aktarım bant genişliği, gecikme ve firewall sorumluluğu net olmalıdır. İnternete açık RDP veya SMB portları, geçiş kolaylığı uğruna varsayılan çözüm olmamalıdır. Kullanıcı erişim tünelleri ile yönetim ağı izinlerini ayrı değerlendirin.

Ağ güvenliği, firewall ve VPN hizmetleri açısından ihtiyaç yalnız tünelin kurulması değildir. Geçiş bittiğinde kullanılmayacak ağ kurallarının kaldırılması, servis hesaplarının gözden geçirilmesi ve logların korunması da planın parçasıdır.

7. SQL Server ve muhasebe uygulamalarında nelere dikkat edilmeli?

Azure VM üzerinde SQL Server, Logo, Mikro veya SAP gibi uygulamaların bulunması durumunda iş yükü daha dikkatli sınıflandırılmalıdır. İşletim sistemi ve veritabanı sürümü, üretici desteği, yedekleme türü, SQL lisansının barındırma koşulları ve uygulama servis bağımlılıkları değerlendirilmeden yalnız sanal disk taşımak yeterli değildir.

SQL veri dosyalarının performansı için disk gecikmesi, okuma-yazma yükü, bellek kullanımı, işlemci profili ve eşzamanlı kullanıcı sayısı ölçülmelidir. Bir sunucunun Azure'da hızlı olması, başka veri merkezinde aynı çekirdek ve RAM sayısıyla aynı performansı vereceğini garanti etmez. İşlemci sınıfı ve depolama mimarisi farklı olabilir.

ERP ve muhasebe uygulamaları için sunucu çözümleri kapsamında veritabanı, uygulama ve uzak erişim katmanlarının ayrı tasarlanması; kullanıcı kabul testinde sipariş, rapor, entegrasyon ve yazdırma gibi gerçek iş akışlarının doğrulanması önemlidir.

8. Geçiş sırasında veri kaybı ve kesinti riski nasıl azaltılır?

Kontrollü geçişte ilk envanterden sonra geri yüklenebilir bir yedek alınır. Hedef ortamda servisler test edilir, dosyaların ilk kopyası hazırlanır, son değişiklikler senkronize edilir ve bakım penceresinde kullanıcı erişimi yeni hedefe yönlendirilir. Her aşama için başarı ölçütü ile eski ortama dönüş kararı yazılı olmalıdır.

RPO (Recovery Point Objective) en fazla ne kadar veri kaybının kabul edileceğini; RTO (Recovery Time Objective) ise iş hizmetinin hangi sürede geri dönmesinin hedeflendiğini ifade eder. Bunlar hizmet verenin kendiliğinden belirleyeceği rakamlar değil, kurumun iş etki analizinden çıkması gereken hedeflerdir.

Yedekleme ve felaket kurtarma kapsamında yalnız yedek işinin başarılı görünmesini değil, seçilen dosyaların ve gerektiğinde uygulamanın geri yüklenmesini kontrol edin. Azure kaynağını silmeden önce lisans, kimlik, DNS, yedek ve servis doğrulaması bitmiş olmalıdır.

9. Azure'dan taşımak gerçekten maliyeti düşürür mü?

Her zaman değil. Azure'da kalmanın, hibrit modelin veya kiralık dedicated/sanal sunucunun maliyeti aynı teknik kapsam için karşılaştırılmalıdır. Hesap yalnız vCPU/RAM aylık ücreti değil; işletim sistemi, SQL/RDS lisansları, veri çıkışı, depolama, yedekleme, firewall/VPN, izleme, güncelleme, taşıma ve şirket içi operasyon emeğini de içermelidir.

Örnek hesap: 12 aylık toplam maliyet = 12 × aylık altyapı/lisans/operasyon bedeli + kurulum ve taşıma giderleri + öngörülen ek maliyetler. Bu bir hesap yöntemi, gerçek teklif veya garanti edilmiş tasarruf iddiası değildir. Sözleşmede döviz kuru, artış koşulları ve KDV açıkça gösterilmelidir.

10. Proje planında kim hangi işi üstlenmeli?

BT ekibi mevcut sistem envanteri, kullanıcı ve uygulama bağımlılıkları, iş kesintisi sınırı ve kabul testlerini belirler. Altyapı sağlayıcısı sözleşmede tanımlanan sunucu, ağ, güvenlik, yedekleme ve yönetim bileşenlerini hazırlar. Uygulama üreticisi veya entegratör uygulamanın yeni ortamda desteklendiğini, lisans ve özel entegrasyon gereksinimlerini doğrular.

Bu sorumlulukları tek bir satıra “taşıma dahil” yazarak geçiştirmek risklidir. Her servis için hazırlık, deneme, geçiş, doğrulama ve geri dönüş sahibini belirleyen bir sorumluluk matrisi hazırlayın. Ayrıca Microsoft 365 oturumları etkilenirse destek alınacak ekip ve iletişim planı net olmalıdır.

İşletimin günlük kısmında patch yönetimi, yedek izleme, sertifika yenileme ve güvenlik olaylarına müdahale gerektiğinden yönetilen sunucu hizmetleri kapsamını kurulum sonrasına bırakmadan görüşün.

11. Azure'dan sunucu kiralamaya geçiş için teklif kontrol listesi

Teklif talebini hazırlarken Azure'da çalışan VM sayısı, sunucu işletim sistemleri, uygulamalar, mevcut kapasite ve disk büyüklüğü, performans grafikleri, AD domain/forest düzeni, DNS ve kimlik eşitleme yapısı, dosya paylaşımları, şube sayısı, VPN ihtiyaçları, hedef kesinti penceresi ve ilk taşınacak servisleri özetleyin.

Teknik keşifte ayrıca depolama büyüme oranı, yedek saklama süresi, hedef RPO/RTO, veri lokasyonu gereksinimi, KVKK açısından erişim ve sözleşme yükümlülükleri, mevcut lisansların kullanılabilirliği, faturalandırma para birimi ve sözleşme sonundaki veri teslim yöntemi belirlenmelidir. KVKK uyumluluğu yalnız sunucu konumuyla sağlanmaz; hukuki inceleme gerekir.

Netsun Bilişim ile adım adım geçiş planı: Önce taşınabilecek ve Azure'da kalması daha uygun olabilecek iş yüklerini ayırın. Ardından kaynak, lisans, güvenlik, yedekleme ve destek ihtiyaçlarının ayrı gösterildiği bir kurumsal teklif isteyin. Azure'dan kurumsal sunucuya geçiş için teklif alın.

Resmî teknik kaynaklar

Bu içerikteki Active Directory ve dosya taşıma yaklaşımı Microsoft'un FSMO rol transferi, Storage Migration Service genel bakışı ve Storage Migration Service uygulama adımları belgelerinden yararlanır. Hibrit kimlik için Microsoft Entra hibrit kimlik ile Cloud Sync önkoşulları incelebilir. İlgili ürün ve sürümün güncel teknik destek koşulları geçiş öncesinde doğrulanmalıdır.

Sık sorulan sorular

1. Azure'dan kiralık sunucuya geçerken Microsoft 365 kapanır mı?

Hayır, zorunlu olarak kapanmaz. Exchange Online, Teams ve SharePoint Online bulutta kalabilir; ancak Active Directory ve Microsoft Entra eşitlemesinin yeni mimaride doğru çalıştığı doğrulanmalıdır.

2. Azure'daki Domain Controller dosyası kopyalanarak taşınabilir mi?

Bu varsayılan ve önerilen geçiş yaklaşımı değildir. AD DS replikasyonu, DNS ve FSMO rolleri dikkate alınarak hedefte yeni Domain Controller kurulumu ve kontrollü devir planı yapılmalıdır.

3. Dosya sunucusu taşınırken NTFS izinleri korunabilir mi?

Uygun yöntem ve testlerle korunması hedeflenebilir. NTFS ACL, paylaşım izinleri, sahiplik, kullanıcı grupları ve UNC yolları ayrı ayrı doğrulanmalıdır.

4. Microsoft Entra Connect veya Cloud Sync yeniden kurulmalı mı?

Mevcut senkronizasyon ajanının nerede çalıştığına ve hedef mimariye bağlıdır. Azure VM'deki sunucu kapatılacaksa kimlik eşitlemesinin kesintisiz sürdürülebilmesi için taşıma veya yeni kurulum planı gerekir.

5. Azure VM'den sunucu kiralamaya geçiş ne kadar sürer?

Sabit süre yoktur. Domain sağlığı, veri hacmi, ağ hızı, uygulama karmaşıklığı, kesinti toleransı ve test kapsamı süreyi belirler. Yazılı plan ve pilot uygulama yapılmalıdır.

6. Azure'dan çıkmak her zaman daha ucuz mudur?

Hayır. Lisans, trafik, yedekleme, güvenlik, destek, kurulum, veri aktarımı ve iç operasyon maliyetleri aynı kapsamda karşılaştırılmadan tasarruf iddiası kurulamaz.

7. Geçişte VPN veya özel ağ bağlantısı zorunlu mu?

AD replikasyonu, dosya aktarımı veya hibrit servis erişimi gerektiren birçok senaryoda güvenli bağlantı gerekir; tam yöntem ve topoloji mevcut ağa göre belirlenmelidir. İnternete açık yönetim portları varsayılan çözüm olmamalıdır.

8. Azure'dan kurumsal sunucuya taşınma teklifi için ne paylaşmalıyım?

VM envanteri, iş uygulamaları, kullanıcı sayısı, AD/DNS mimarisi, dosya hacmi, mevcut maliyet kalemleri, şube bağlantıları, yedekleme ve hedef geçiş tarihini paylaşın. Kurumsal sunucu taşıma teklif formunu doldurun.