Bu rehber neyi çözer?
Linux birçok sunucu rolünde Windows Server’ın güçlü bir alternatifi olabilir; ancak tam yerine geçip geçemeyeceği iş yüküne bağlıdır. Karar işletim sistemi değil servis/rol bazında verilmelidir.
Kısa cevap: Nerede geçebilir, nerede zorlanır?
Linux; web/reverse proxy, DNS, DHCP, veritabanı, dosya paylaşımı, container host, monitoring, backup hedefi ve KVM tabanlı sanallaştırma rollerinde güçlü bir alternatiftir.
Windows’a özel .NET Framework uygulamaları, yoğun Group Policy bağımlılığı, belirli vendor yazılımları ve ileri Microsoft AD özelliklerinde geçiş daha karmaşıktır.
Bu nedenle hedef bütün Windows sunucuları kaldırmak değil, Linux’a uygun rolleri belirlemek olmalıdır.
Linux’un fazla olduğu taraflar
Genellikle daha düşük işletim sistemi lisans maliyeti, güçlü SSH/otomasyon yaklaşımı, olgun paket yönetimi ve geniş açık kaynak servis ekosistemi sağlar.
Nginx/Apache, PostgreSQL/MariaDB, Samba/NFS, KVM/QEMU ve Docker/Podman gibi olgun bileşenler birçok kurumsal rolü karşılar.
Yapılandırma dosyası ve Infrastructure-as-Code yaklaşımı ölçekli yönetimi kolaylaştırabilir.
Windows Server’ın güçlü kaldığı taraflar
Active Directory, Group Policy, Microsoft merkezli istemci yönetimi, Windows’a özel uygulamalar ve bazı üretici destek modelleri Windows Server’ı doğal seçenek yapabilir.
Samba AD DC önemli AD işlevleri sağlayabilir; ancak karmaşık GPO, Entra/AD hibrit yapısı, AD CS veya Microsoft ürün bağımlılıklarında birebir eşdeğerlik varsayılmamalıdır.
Ekibin Linux operasyon yetkinliği yoksa teknik olarak mümkün bir geçiş operasyonel risk yaratabilir.
Rol bazında teknik karşılaştırma
Web/reverse proxy: Linux çoğu senaryoda çok güçlüdür. Dosya sunucusu: Samba ile SMB paylaşımı mümkündür. Domain/kimlik: Samba AD DC mümkündür ama ileri Microsoft özellikleri ayrıca test edilmelidir.
Veritabanı: PostgreSQL/MariaDB gibi iş yükleri Linux’ta doğal çalışır; SQL Server’a veya Windows bileşenlerine bağımlı uygulamalar pilot gerektirir.
Sanallaştırma: KVM/QEMU olgundur; mevcut Hyper-V yönetim ve backup süreçleri yeniden tasarlanmalıdır. Container: Linux genellikle en doğal platformdur.
Geçişte en sık atlanan konular
Kimlik/ACL, servis hesapları, DNS, loglama, monitoring, yedekleme, patch, sertifika, vendor desteği ve uygulama lisansları birlikte değerlendirilmelidir.
Uygulamanın yalnız açılması yeterli değildir; performans, failover, backup/restore, güvenlik ajanı ve operasyon prosedürü test edilmelidir.
Hibrit mimari çoğu kurum için tek seferde tam geçişten daha kontrollü başlangıçtır.
Önerilen geçiş planı
1) Sunucu/rol envanteri çıkarın. 2) Bağımlılıkları haritalayın. 3) Linux’a uygun adayları seçin. 4) Pilot kurun. 5) Performans ve entegrasyon testleri yapın. 6) Backup/restore ve rollback doğrulayın. 7) Kademeli üretim geçişi yapın.
Özellikle web, monitoring, container, yardımcı altyapı ve bazı dosya servisleri ilk dalga için uygun adaylar olabilir.
Sık Sorulan Sorular
Linux Active Directory’nin tamamen yerini alabilir mi?
Samba AD DC birçok temel ve ileri AD işlevini sağlayabilir; ancak karmaşık GPO, Microsoft hibrit kimlik ve ürün bağımlılıklarında birebir eşdeğer varsayılmamalıdır.
Windows Server lisans maliyeti tamamen ortadan kalkar mı?
Linux’a taşınan roller için OS lisansı azalabilir; destek, yönetim, eğitim, uygulama lisansı ve geçiş maliyetleri toplam sahip olma hesabına dahildir.
En kolay hangi roller Linux’a taşınır?
Web/reverse proxy, yardımcı DNS/DHCP, monitoring, container host, bazı dosya ve veritabanı iş yükleri genellikle iyi başlangıç adaylarıdır.
Kaynaklar ve teknik referanslar
Linux Sunucu Projenizi Değerlendirelim
Mevcut Windows/Linux rollerinizi, uygulama bağımlılıklarını ve geçiş hedeflerinizi birlikte değerlendirebiliriz.
Mimari ve çalışma modeli
Geçiş kararı işletim sisteminin adından değil servis rolünden çıkarılır. Web, uygulama ve bazı dosya servisleri için Linux uygun olabilirken üretici destekli Windows uygulaması veya belirli domain özellikleri farklı tasarım gerektirir. Kimlik, dosya izinleri, yönetim aracı ve backup entegrasyonu rol bazında eşleştirilmelidir.
- 1Servis rolü envanteri
- 2Uyumluluk ve destek
- 3Pilot ve veri/kimlik testi
- 4Karma veya tam geçiş
Tasarım parametreleri
- İşlev ve protokol
- Dosya, kimlik, uygulama ve yönetim rollerini ayrı değerlendirin; işletim sistemi eşdeğerliği protokol uyumu değildir.
- Destek ve işletim
- Üretici desteği, ekip yetkinliği ve yama/kurtarma akışını toplam geçiş maliyetine ekleyin.
- Servis ve kullanıcı
- Gerçek servis kullanıcısını, grup üyeliğini, çalışma dizinini ve gerekli yetkileri listeleyin. Root ile başarılı test sınırlı hesapla çalışmayı kanıtlamaz.
- Depolama ve kalıcılık
- Mount, dosya sistemi, inode ve kalıcı veriyi birlikte kontrol edin. Yeniden başlatma ve yeniden oluşturma aynı test değildir.
- Ağ ve güvenlik katmanı
- Dinlenen arayüz, firewall, TLS ve SELinux/AppArmor politikalarını ayırın. Bir katmandaki engel başka katmanın ayarıyla çözülmez.
- Paket ve işletim yöntemi
- Sürüm, depo, güncelleme yöntemi ve servis bağımlılıklarını belgeleyin. Bakım sonrası reboot ve uygulama doğrulamasını planlayın.
Hesap ve uygulama örneği
Örnek keşifte her Windows servisi için protokol, veri, kimlik, destek ve kurtarma bağımlılığı yazılır. Bir dosya paylaşımı pilotla taşınabilirken uygulama sunucusu üretici desteği nedeniyle kalabilir. Karma yapı normal bir sonuçtur; hedef bütün sistemleri tek OS’ye zorlamak değildir.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Pilot açılıyor ama eski istemci çalışmıyor | Protokol, authentication veya uygulama desteği farklı olabilir. | Gerçek istemci ve kimlikle tüm iş akışını pilotta çalıştırın. |
| Servis aktif ama yanıt vermiyor | Process sağlığı, port dinleme ve uygulama sağlığı farklı kontrollerdir. | Yerel sağlık kontrolünü uzak istemci isteğiyle karşılaştırın; log ve bağımlılık durumunu inceleyin. |
| Dosya yazılamıyor | İzin, ACL, read-only mount, inode veya disk doluluğu etkili olabilir. | Servis kimliğiyle dizin zincirini ve mount durumunu doğrulayın; izinleri topluca açmayın. |
| Reboot sonrası yapılandırma kayboldu | Geçici mount, runtime ayarı veya yanlış yapılandırma kaynağı kullanılmış olabilir. | Kalıcı ayarı ve açılış sırasını kontrol edin; temiz reboot testini tekrarlayın. |
Kabul ve doğrulama kontrolleri
- Kararı rol bazında uygulama desteği ve gerçek geri dönüş testiyle doğrulayın.
- Servisi tanımlanan sınırlı kimlikle çalıştırıp temel iş akışını test edin.
- Reboot sonrasında mount, ağ, zaman ve uygulama durumunu doğrulayın.
- Yapılandırma, veri ve anahtarları ayrı kurtarma kalemleri olarak kaydedin.
- Güncellemeden önce ve sonra aynı sağlık testini çalıştırın.
- Ayrı hedefe geri yükleyerek platform bağımlılıklarını doğrulayın.
İlgili kavramlar
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACL’leri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Dosya sistemi ve depolama katmanları
Uygulama dizini, mount point, mantıksal disk ve fiziksel depolama aynı katman değildir. Boş alan kadar inode tükenmesi, read-only mount ve dosya sistemi hataları da yazmayı durdurabilir. Snapshot genellikle aynı depolama arızasını paylaşır ve bağımsız yedek sayılmaz. Mount seçenekleri ve kapasite genişletme yöntemi dosya sistemine göre değişir. İşletim sistemi yeniden açıldığında doğru depolamanın doğru dizine bağlandığını doğrulayın; mount edilmeyen dizine yazılan veri yanlış diski doldurabilir.
Servis yaşam döngüsü ve bağımlılıklar
Çalışan bir process, hizmetin kullanıcıya doğru yanıt verdiğini kanıtlamaz. Başlangıç sırası, ağ veya veritabanı bağımlılığı, ortam değişkenleri, dosya erişimi ve sağlık kontrolü birlikte incelenir. Servis yeniden başlatma döngüsü bazen gerçek nedeni gizler. Exit code, son loglar ve kaynak sınırlarını karşılaştırın. Uygulama dışında systemd veya container yönetim katmanının neden yeniden başlatma yaptığını da kaydedin. Kontrollü restart sonrasında oturum, veri yazma ve bağımlı servislerin davranışını doğrulayın.
İzolasyon ile sanallaştırma ayrımı
Container ve sanal makine aynı izolasyon sınırını sunmaz. Containerlar host çekirdeğini paylaşırken sanal makineler konuk işletim sistemi çalıştırır. Rootless kullanım, namespace ve capability kısıtları riski azaltabilir; yapılandırma ve host güvenliği yine önemlidir. Image, çalışan container ve kalıcı volume ayrı yaşam döngülerine sahiptir. Image güncellemek veriyi yedeklemez. Testte process izinlerini, mountları, ağ erişimini ve kalıcı verinin yeniden oluşturma sonrasında korunmasını ayrı ayrı doğrulayın.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.