Çok Şubeli Şirketler İçin Merkezi Sunucu Kiralama Rehberi

Çok şubeli şirketler için merkezi sunucu kiralama, farklı ofislerdeki kullanıcıların şirket uygulamalarına, dosyalarına ve kimlik hizmetlerine ortak ve kontrollü bir altyapı üzerinden erişmesini sağlayan hizmet modelidir. Her şubeye ayrı bir sunucu kurmak yerine uygun iş yükleri merkezi bir veri merkezinde çalıştırılabilir. Ancak tek noktadan yönetim, tek noktaya bağımlılık yaratmamalıdır: bağlantı, kimlik doğrulama, yedekleme ve erişim sürekliliği birlikte tasarlanmalıdır.

Kısa cevap: Merkez ve şubelerde kullanılan uygulamaları envanterleyin; Active Directory, dosya, ERP ve uzak masaüstü iş yüklerini ayrı değerlendirin. Şubelerden veri merkezine güvenli bağlantı tasarlayın, eş zamanlı kullanıcı sayısını ve gerçek ağ gecikmesini ölçün, kritik hizmetleri yedekli planlayın. Ardından sunucu, lisans, yönetim ve kurtarma kapsamını tek teklifte karşılaştırın. Kurumunuza özel mimari için çok şubeli sunucu kiralama teklifi alın.

Bu rehber; iki veya daha fazla lokasyonu olan perakende, dağıtım, üretim, muhasebe ve hizmet işletmelerinin BT yöneticileri ile satın alma ekiplerine yöneliktir. Buradaki örnek mimariler kesin donanım önerisi ya da Netsun Bilişim tarafından verilmiş bir çalışma süresi garantisi değildir.

1. Hangi durumlarda şubeler için merkezi sunucu kiralama mantıklı?

Her şubede aynı uygulamanın farklı kopyalarının bulunması sürüm uyuşmazlığına, parçalı kullanıcı yetkilerine ve zor yönetilen yedeklere yol açabilir. Ortak ERP veritabanı, merkezî kimlik yönetimi, dosya paylaşımı veya tek bir raporlama ortamı gerekiyorsa merkezi altyapı daha tutarlı bir operasyon sağlayabilir.

Merkezî mimari, tüm işlevlerin mutlaka tek sunucuda çalışması anlamına gelmez. Kimlik, uygulama, veritabanı ve dosya katmanlarının gerektiğinde ayrılması güvenlik, performans ve bakım açısından değerlidir. Ofiste internet kesildiğinde çalışmaya devam etmesi gereken barkod, üretim hattı veya kasa süreçleri için ise yerel bileşenler ve kontrollü çevrimdışı işleyiş gerekebilir.

Satın alma kararını verirken şu soruyu öne alın: “Hangi sistemler tüm lokasyonlarda ortak olmalı, hangileri bağlantı kesilse de şubede çalışmalı?” Doğru cevap, şirketin faaliyetini ve uygulama üreticisinin desteklediği çalışma modelini yansıtmalıdır.

2. Active Directory ve DNS şubeler arasında nasıl planlanır?

Active Directory Domain Services (AD DS), kullanıcı hesapları, bilgisayarlar, grup ilkeleri ve kimlik doğrulama süreçlerini merkezi yönetime bağlayabilir. Ancak etki alanı denetleyicisinin veri merkezinde olması tek başına her şubede hızlı oturum açma garantisi vermez. DNS bağımlılıkları, bağlantı gecikmesi, ağ kesintisi ve yerel iş gereksinimleri ayrıca düşünülmelidir.

Microsoft'un Active Directory site topolojisi tasarım rehberi, fiziksel ağın siteler, alt ağlar ve site bağlantılarıyla temsil edilmesini önerir. Şubelerin IP alt ağları doğru tanımlanmazsa istemcilerin uygun etki alanı denetleyicisini bulması zorlaşabilir. Replikasyon trafiği ve bağlantı maliyeti de planın parçasıdır.

Az kullanıcılı bazı ofisler merkezi bir domain controller üzerinden çalışabilirken bağlantı güvenilirliği düşük veya kesintide kimlik doğrulaması kritik olan lokasyonlarda ek domain controller ya da uygun koşullarda read-only domain controller seçenekleri incelenebilir. Active Directory ve dosya hizmetleri mimarisi, kimlik, DNS ve dosya yetkilerinin birlikte ele alınmasına yardımcı olur. Şube başına domain controller gereksinimi otomatik bir kural değildir.

3. Şube ile veri merkezi arasındaki VPN bağlantısı nasıl kurulmalı?

Her şubeden veri merkezine site-to-site IPsec VPN kurulması, kurumsal uygulama ve sunuculara kontrollü erişim için yaygın bir seçenektir. Bazı yapılarda özel hat veya operatörün yönetilen bağlantısı da tercih edilebilir. Bağlantı tasarımında karşı uçların güvenlik duvarı kapasitesi, şifreleme yükü, rota kuralları ve failover davranışı hesaba katılmalıdır.

VPN'in bağlı görünmesi, ERP ve dosya hizmetlerinin sorunsuz çalıştığı anlamına gelmez. Şubeden veri merkezine gerçek uygulama testi yapın; çift yönlü erişim, MTU/MSS, DNS çözümleme, paket kaybı, gecikme ve tünel yeniden kurulma süresini kontrol edin. Birincil internet hattı arızalanınca ikincil hat üzerinden hangi servislerin devam edeceği ayrıca denenmelidir.

Ağ ve güvenlik hizmetleri için teklifte şube tüneli sayısını, güvenlik duvarı lisansını, erişim politikalarını, kayıt saklama ve müdahale sorumluluğunu açıkça isteyin. Doğrudan internete açık SMB, SQL Server veya yönetim amaçlı RDP bağlantılarını, kolay kurulum sağladığı gerekçesiyle varsayılan çözüm olarak kullanmayın.

4. ERP, Logo, Mikro veya SAP uygulamalarına şubelerden erişim

Muhasebe ve ERP uygulamaları merkezî kurulumdan yararlanabilir; ancak kullanılacak bağlantı yöntemi ürün ve sürüme bağlıdır. Bazı iş uygulamaları uzak ağ üzerinden istemci-veritabanı bağlantısında yüksek gecikmeden olumsuz etkilenir. Bazılarında merkezi uygulama sunucusunda oturum açmak veya üreticinin desteklediği web arayüzünü kullanmak daha uygun olabilir.

Önce ürün sürümü, eş zamanlı kullanıcı, veritabanı boyutu, rapor yükü, e-belge entegrasyonları ve istemci gereksinimlerini doğrulayın. SQL Server için yoğun saatlerde CPU/RAM yanında disk gecikmesini ve işlem yükünü ölçün. Beş şubenin olması tek başına kaç vCPU gerektiğini belirlemez; aynı şubede iki kullanıcının basit veri girişi ile yoğun stok raporu farklı kaynak tüketir.

ERP ve muhasebe uygulamaları sunucu çözümleri değerlendirilirken uygulama üreticisinin desteği ile altyapı sağlayıcısının sorumluluğu ayrılmalıdır. Logo, Mikro, Zirve veya SAP için tek bir lisanslama ve taşıma kuralı uydurulamaz; ürünün desteklenen barındırma modeli önceliklidir.

5. RDS veya RemoteApp ile merkezi uygulama erişimi gerekli mi?

Uzak şubelerde çalışan Windows masaüstü uygulamaları için Remote Desktop Services (RDS) ve uygun senaryolarda RemoteApp değerlendirilebilir. Böyle bir modelde kullanıcı uygulamayı sunucu oturumunda çalıştırır; ekran ve etkileşim verisi istemciye aktarılır. Veritabanı ile uygulama katmanının yakın olması, bazı yüksek gecikmeli bağlantılarda kullanım deneyimini iyileştirebilir.

Bununla birlikte RDS her işletme için zorunlu değildir. Üreticinin çok oturumlu çalışma desteği, kullanıcı profili, yazıcı yönlendirme, USB/akıllı kart cihazları ve eş zamanlı oturum kaynakları test edilmelidir. Microsoft'un RDS planlama rehberi, erişim, kapasite, yüksek erişilebilirlik ve güvenliği birlikte değerlendirir.

Çalışanların Windows Server üzerinde RDS oturumlarını kullanması durumunda uygun RDS CAL veya geçerli hizmet sağlayıcı lisanslama modeli belirlenmelidir; sadece Windows Server lisansı bu gereksinimi otomatik ortadan kaldırmaz. Microsoft'un RDS CAL rehberi, sürüm uyumluluğunu da açıklar. Farklı uzak erişim modellerinin karşılaştırması için Terminal Server, RDS ve RemoteApp rehberini inceleyebilirsiniz.

6. Merkezi dosya paylaşımında performans ve yetkilendirme

Merkezi file server, şubelerdeki çalışanların ortak belge havuzuna ve yönetilen klasör yetkilerine erişmesini kolaylaştırabilir. Ancak büyük CAD dosyaları, yoğun küçük dosya işlemleri veya uygulamaların sürekli SMB bağlantısı kullanması WAN gecikmesine duyarlı olabilir. Bunun için sadece internet hızının indirme değerine bakmak yeterli değildir.

Microsoft'un SMB dosya sunucusu performans rehberi, sunucu ve ağ sürücüleri, SMB ayarları ile iş yükü davranışının birlikte değerlendirilmesini açıklar. Güvenlik özelliklerini sırf hız amacıyla kapatmak yerine, darboğazın kaynağını ölçerek çözüm belirleyin.

NTFS ve paylaşım izinleri, grup üyelikleri, kullanıcı silme/işten ayrılma süreçleri, dosya kilitleme ve sürüm geçmişi de tasarımın parçasıdır. Şubelerde sınırlı çevrimdışı erişim gerekiyorsa uygulamanın veri tutarlılığıyla uyumlu bir yöntem seçilmelidir. Dosya sunucusunun tek kopyasıyla değil, ayrı ve doğrulanmış yedeklerle korunması gerekir.

7. VPS, dedicated veya hibrit altyapı nasıl seçilir?

Sanal sunucular, kimlik, uygulama ve dosya hizmetlerini ayrı makineler hâlinde ölçeklendirmek isteyen kurumlar için esnek olabilir. Sürekli yüksek SQL yükü, özel donanım veya belirli lisans koşullarında fiziksel sunucu ihtimali ayrıca değerlendirilmelidir. Tek bir iş yükünü merkezîleştirmek ile tüm kurumu aynı fiziksel cihaza taşımak farklı kararlardır.

VPS ve bulut sunucu seçenekleri için vCPU/RAM yanında disk türü, gerçek gecikme, depolama büyümesi, özel ağ, IP ve yedekleme tasarımını sorun. Hibrit mimaride bazı kritik servisler ofiste veya başka bir bulutta kalabilir; sırf merkezî yönetim istendiği için tüm servisleri taşımak zorunlu değildir.

Bu karar tablosu hazır paket değildir. Gerçek ölçüm olmadan “şube başına şu kadar RAM” ya da “her şirket için tek dedicated makine” gibi kesin öneriler yanıltıcı olabilir.

8. İnternet kesilirse bütün şubeler durur mu?

Merkezî altyapı kurulurken en önemli risklerden biri, her şubenin tek internet hattına ve tüm iş süreçlerinin tek merkez sunucuya bağımlı hâle gelmesidir. Hangi işin çevrimdışı sürdürülebileceği, hangi işlemin ertelenebileceği ve hangisinin merkez ile eş zamanlı iletişim gerektirdiği iş birimiyle sınıflandırılmalıdır.

Örneğin bir perakende şubesinde satış uygulamasının bağlantısız kullanımını destekleyip desteklemediğine yazılım üreticisi karar verir. Desteklenmeyen bir uygulamada kendi başına yerel kopya üretmek veri bütünlüğü sorunları yaratabilir. Alternatif internet hattı, otomatik VPN geri dönüşü, yerel DNS/kimlik seçeneği veya iki lokasyonlu hizmet mimarisi ihtiyaca göre planlanmalıdır.

Kesinti senaryolarını test ederken yalnız ana sunucuyu kapatmak yeterli değildir: şube interneti, DNS, VPN cihazı, domain controller, ERP veritabanı ve yedek bağlantısı için ayrı arıza senaryoları uygulayın. Her durumun işletme üzerindeki etkisini ve geri dönüş sorumlusunu yazılı kaydedin.

9. Merkezi sunucu için yedekleme ve felaket kurtarma nasıl olmalı?

RAID, sanal makine snapshot'ı veya çalışan ikinci sunucu, bağımsız ve doğrulanmış yedeğin yerine geçmez. Şirketin muhasebe verisi, Active Directory, dosya paylaşımı ve önemli uygulama yapılandırmaları için kurtarma önceliklerini ayrı belirleyin. Her iş yükünün kabul edilebilir veri kaybı ve toparlanma süresi aynı olmayabilir.

RPO kabul edilebilir veri kaybı aralığıdır; RTO hizmetin geri dönmesi için belirlenen hedeftir. İki değer sözleşmeye yazılmadan önce iş birimlerince kabul edilmeli ve teknik olarak test edilmelidir. Birden fazla şubenin aynı hizmete bağımlı olması, merkezi sunucudaki sorunun daha geniş etki yaratabileceği anlamına gelir.

Yedekleme ve felaket kurtarma hizmetleri teklifinde yedek sıklığı, şifreleme, ayrı güvenlik alanı, saklama, silinmeye karşı koruma, geri yükleme testi ve kimin müdahale edeceği açık olsun. Yalnızca “günlük yedek var” ifadesi, çalışır kurtarma planının kanıtı değildir.

10. Çok şubeli sunucu kiralamanın aylık maliyetini neler etkiler?

Toplam maliyeti yalnız sunucu CPU/RAM kapasitesi belirlemez. Şubelerin bağlantı gideri, güvenlik duvarı ve VPN lisansları, Windows Server ile SQL Server lisanslama modeli, gerekiyorsa RDS CAL, yönetim desteği ve yedek kapasitesi ayrı kalemlerdir. İlk kurulum, uygulama taşıma, veri temizleme ve test hizmetleri tek seferlik maliyet oluşturabilir.

Örneğin beş şubesi ve otuz eş zamanlı kullanıcısı olduğu varsayılan temsili bir şirket için tek sunucu fiyatı söylemek doğru değildir. Kullanıcıların ERP mi yoksa dosya mı kullandığı, veritabanı boyutu, bağlantı gecikmesi ve beklenen kesinti toleransı bilinmeden aynı rakam iki farklı işletmede doğru olamaz.

Maliyet teklifinde aylık sunucu kirasını, lisansları, şube-VPN kalemlerini, yedekleme bedelini, yönetilen hizmeti ve devreye alma işlerini ayrı görün. Düşük ilk ücret karşılığında destek, yedekleme veya veri taşıma kapsamı dışarıda kalıyorsa karşılaştırma eşit şartlarda değildir.

11. Kurulum ve devreye almada 10 maddelik kabul listesi

Satın alma öncesinde aşağıdaki kontrol listesini doldurmak, hem BT hem finans ekibinin teklifi aynı ölçütle değerlendirmesini sağlar:

1. Şube, kullanıcı, uygulama, cihaz ve veri hacmi envanteri tamamlandı mı?
2. Active Directory, DNS, ERP/SQL ve dosya servislerinin bağımlılık haritası çıkarıldı mı?
3. Şube başına VPN/topoloji, yedek internet ve rota testleri belirlendi mi?
4. Gerçek CPU/RAM/IOPS kullanımı ile WAN gecikmesi ölçüldü mü?
5. Uygulama üreticisinin barındırma, lisans ve RDS uyumluluğu doğrulandı mı?
6. Kullanıcı, klasör ve yönetici erişim yetkileri test edildi mi?
7. Yedek sıklığı, RPO/RTO ve geri yükleme senaryosu belgelendi mi?
8. İzleme, alarm, bakım penceresi ve müdahale yetkileri yazıldı mı?
9. En az bir pilot şubede gerçek iş akışı ve bağlantı arızası testi yapıldı mı?
10. Kabul kriteri, geçiş takvimi, geri dönüş kararı ve sözleşme sorumluları belli mi?

Kurumsal yönetilen sunucu hizmetleri değerlendirilirken altyapı sağlayıcısının işletim sistemi ve ağ yönetimini, ERP üreticisinin uygulama desteğini hangi sınırlarla üstlendiğini sözleşmede ayrı gösterin. İzleme hizmeti varsa hangi alarmların mesai dışında da takip edileceğini ve işin kime devredileceğini netleştirin.

12. İşletmeniz için doğru sunucu kiralama teklifi nasıl hazırlanır?

Doğru teklif ilk olarak şirketinizin şube sayısını, kullanıcı profilini, hangi uygulamanın nerede çalıştığını ve kritik kesinti senaryolarını temel almalıdır. Sunucu özellikleri bundan sonra seçilir. Teknik keşif sonucunda sanal, fiziksel veya hibrit altyapı önerilebilir; şartları doğrulanmamış tek bir paket tüm müşterilere uygun kabul edilmemelidir.

Netsun Bilişim'den teklif isterken şehir ve şube sayısını, eş zamanlı kullanıcı sayısını, ERP/SQL sürümlerini, Active Directory durumunu, dosya kapasitesini, VPN cihazlarını, mevcut internet hatlarını, yedekleme beklentisini ve hedef geçiş tarihini paylaşın. Böylece teklif yalnız makine kirasını değil, kurulumdan sonraki işletme ve kurtarma sorumluluğunu da kapsayabilir.

Şubelerinizde ortak ERP, dosya ve kullanıcı yönetimini planlıyorsanız çok şubeli kurumsal sunucu kiralama için ihtiyaç analizi ve teklif talep edin. Amacımız, performansı ve güvenliği ölçülebilen, sözleşme kapsamı açık ve işinizin büyümesine uyum sağlayan bir altyapı kararı vermenize yardımcı olmaktır.

Sık sorulan sorular

1. Her şubeye ayrı bir sunucu kurmak zorunda mıyız?

Hayır. Merkezi sunucu mimarisinde birçok iş yükü ortak altyapıda çalışabilir. Ancak internet kesintisinde çalışması gereken süreçler, kimlik erişimi ve üretici desteği değerlendirilerek bazı bileşenler şubede kalabilir.

2. Şubeler arası VPN tek başına güvenli erişim sağlar mı?

VPN, şifreli bağlantı katmanıdır; tek başına tüm güvenliği sağlamaz. Uç nokta güvenliği, yetki sınırları, çok faktörlü kimlik doğrulama, güncelleme, firewall kuralları ve izleme birlikte planlanmalıdır.

3. Merkezi sunucu için kaç vCPU ve ne kadar RAM gerekir?

Şube sayısına dayalı sabit bir formül yoktur. Aynı anda çalışan kullanıcı, ERP sorguları, SQL veritabanı boyutu, dosya trafiği ve RDS oturumları ölçülerek kaynak planı yapılmalıdır.

4. Şubelerdeki kullanıcılar aynı Active Directory hesabını kullanabilir mi?

Uygun AD DS tasarımında kullanıcı ve bilgisayar hesapları merkezi yönetilebilir. Ancak DNS, ağ erişimi, site-alt ağ eşlemesi ve bağlantı kesintisinde oturum açma davranışı ayrıca test edilmelidir.

5. Çok şubeli şirketler için RDS lisansı zorunlu mudur?

RDS kullanılıp kullanılmadığı belirleyicidir. Çalışanlar Windows Server üzerindeki RDS oturumlarına bağlanıyorsa geçerli CAL veya ilgili hizmet sağlayıcı lisanslama koşulları değerlendirilmelidir; yalnız sunucu kiralamak otomatik RDS zorunluluğu yaratmaz.

6. İnternet kesilince ERP verileri kaybolur mu?

Bağlantı kesintisi tek başına veri kaybı anlamına gelmez; ancak oturum ve işlem davranışı uygulamaya göre değişir. Veri bütünlüğü, son başarılı işlem, yedek ve çevrimdışı kullanım desteği üreticiyle test edilmelidir.

7. Sunucu kiralama fiyatı şube sayısına göre mi hesaplanır?

Şube sayısı bağlantı ve güvenlik kapsamını etkileyebilir; fakat toplam fiyat sunucu, kullanıcı, uygulama, lisans, trafik, yedekleme ve yönetim giderlerinin birleşimidir. Eşit kapsamda teklif karşılaştırılmalıdır.

8. Çok şubeli sunucu kiralama teklifi için hangi bilgileri vermeliyiz?

Şube sayısı ve lokasyonlar, eş zamanlı kullanıcı sayısı, ERP/SQL sürümü, Active Directory ve dosya hacmi, mevcut VPN ve internet altyapısı, yedekleme hedefleri ile geçiş tarihi yeterli bir başlangıç oluşturur. Şubeleriniz için özel sunucu kiralama teklifi isteyin.