Ana içeriğe geç

SecuraWall.com

E-posta güvenliği ve sürekliliği

Keşfedin

Karşılaştırma · Sunucu ve Sanallaştırma

Backup MX Appliance: Cihaz mı, Bulut Hizmeti mi?

Backup MX appliance ile bulut Backup MX hizmeti aynı süreklilik hedefini farklı işletim modelleriyle ele alır. Kararı cihaz fiyatı yerine bağımsız hata alanı, bakım sorumluluğu, kapasite…

Teknik gözden geçirme:

Mimari ve çalışma modeli

Backup MX appliance ile bulut Backup MX hizmeti aynı süreklilik hedefini farklı işletim modelleriyle ele alır. Kararı cihaz fiyatı yerine bağımsız hata alanı, bakım sorumluluğu, kapasite ve kurtarma testi üzerinden vermek gerekir.

Fiziksel veya sanal cihaz kullanıldığında işletim sistemi, depolama, yama, sertifika, izleme ve yedeklilik kurumun ya da hizmet ortağının sorumluluğundadır. Birincil sunucuyla aynı elektrik, internet hattı ve yönetim hesabını paylaşan ikinci cihaz, o kaynaklar kesildiğinde birlikte devre dışı kalabilir. Ayrı lokasyon ve yönetim sınırı tasarımın parçasıdır.

Bulut hizmeti yerel donanım edinimini ve bazı bakım görevlerini azaltabilir; yine de hizmet sağlayıcının kesinti davranışı, veri işleme koşulları, yönetim erişimi ve kapasite sınırları değerlendirilir. Abonelik, bütün işletim sorumluluğunu ortadan kaldırmaz: DNS, hedef kabulü, alıcı bilgisi ve olay takibi müşterinin kontrolünü gerektirir.

Doz Teknoloji bu iki modeli mevcut ekip ve altyapıya göre karşılaştırır. Yerel kontrol gereksinimi güçlü bir kurum için bağımsız lokasyonda cihaz uygun olabilir; küçük bir operasyon için yönetilen bulut hizmeti daha az bakım yükü doğurabilir. SecuraWall burada bulut hizmeti örneğidir. Filtreleme gereksinimi varsa bağımsız Backup MX yerine güvenlik geçidi kapsamı ayrıca incelenmelidir.

  1. 1İş ve veri gereksinimi
  2. 2Hata alanı ve sorumluluk
  3. 3Eşdeğer kapsamda maliyet
  4. 4Pilot ve kurtarma tatbikatı
Seçim, bağımsızlık ve sürdürülebilir işletim kanıtıyla gerekçelendirilmelidir.

Tasarım parametreleri

Bağımsızlık
Enerji, internet, lokasyon, DNS ve yönetici kimliğini ayrı değerlendirin; yalnız ikinci cihaz sayısını yüksek erişilebilirlik ölçütü yapmayın.
İşletim sahipliği
Yama, sertifika, disk doluluğu, alarm ve mesai dışı müdahalenin sahibini yazın.
Maliyet kapsamı
Donanım, lisans, ikinci lokasyon, bağlantı, personel zamanı, yenileme ve çıkış giderlerini aynı dönem için hesaplayın.
Veri ve çıkış
Geçici mesajların konumu, kayıt erişimi, silme davranışı ve abonelik sonundaki kuyruk işlemini sorun.

İşletim sorumluluklarıyla karşılaştırma

Aşağıdaki farklar genel tasarım ölçütleridir. Seçilen cihaz, hizmet sözleşmesi ve kurulum modeli sonucu değiştirebilir.

ÖlçütKurumun işlettiği cihazYönetilen bulut hizmeti
Altyapı bakımıKurum veya hizmet ortağı planlarSağlayıcı kapsamına göre paylaşılır
Kesinti bağımsızlığıAyrı enerji, hat ve yer tasarlanırSağlayıcının hata alanları doğrulanır
Kapasite artışıDisk, işlemci ve lisans planı gerektirirPaket sınırı ve büyüme koşulları değerlendirilir
MaliyetYatırım ve sürekli işletim birlikte hesaplanırAbonelik ve ek operasyon giderleri hesaplanır
Teslimat sorumluluğuKuyruk ve hedef kabulü izlenirHizmet kaydı ile hedef kabulü eşleştirilir

Hesap ve uygulama örneği

Tamamen varsayımsal üç yıllık hesapta cihaz 2.400 USD, ikinci lokasyon ve bağlantı ayda 80 USD, bakım emeği ayda 50 USD olsun. Toplam 2.400 + 36 × (80 + 50) = 7.080 USD olur. Bir bulut seçeneği ayda 40 USD abonelik ve 15 USD iç operasyon zamanı gerektiriyorsa aynı dönem 1.980 USD'dir. Bunlar piyasa fiyatı veya SecuraWall teklifi değildir; hesap yöntemi örneğidir.

Maliyet farkını karar vermeden önce aynı hizmet kapsamıyla karşılaştırın: kaç alan adı, hangi kuyruk kapasitesi, hangi destek saati ve hangi kesinti bağımsızlığı sağlanıyor? Ucuz seçenek gerekli veri yerleşimini karşılamıyorsa maliyet tablosu tek başına belirleyici olamaz. Her iki seçenek için aynı kesinti ve geri dönüş tatbikatını yapın; yalnız satın alma bedelini kıyaslamayın.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
İki cihaz da aynı anda kesiliyorOrtak enerji, hat veya yönetim bağımlılığı olabilir.Tek olayın etkilediği bileşenleri hata alanı haritasında gösterin.
Abonelik ucuz, toplam gider beklenenden yüksekDestek, ek kapsam veya iç operasyon dışarıda bırakılmış olabilir.Aynı süre ve hizmet kapsamıyla toplam maliyeti yeniden çıkarın.
Geçişte bekleyen mesajlar belirsizÇıkış sırasında kuyruk sahipliği planlanmamış olabilir.Kabul edilmiş mesajların sonuçlarını ve kapanış takvimini yazılı eşleştirin.

Kabul ve doğrulama kontrolleri

  1. Cihaz ve bulut için aynı gereksinim listesini kullanın.
  2. Ortak hata alanlarını ve ayrı yönetim erişimini doğrulayın.
  3. Bütün bakım görevlerine sorumlu atayın.
  4. Aynı süre ve kapsam için toplam maliyeti hesaplayın.
  5. Veri, kapasite ve hizmetten çıkış koşullarını inceleyin.
  6. Seçenekleri aynı kesinti ve teslimat testiyle karşılaştırın.

İlgili kavramlar

Güven sınırı ve hata alanı

Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.

Yüksek erişilebilirlik ile kurtarma ayrımı

Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.

Kapasite ve kullanılabilir pay

Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.

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.

En az yetki ve görev ayrımı

En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.

Politikanın yaşam döngüsü

Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.

Birincil teknik dokümantasyon

Bulut e-posta güvenliği ve sürekliliğini değerlendirin

Doz Teknoloji tarafından işletilen SecuraWall MailFlow ile bulut e-posta güvenliği ve Backup MX seçeneklerini inceleyin. Kurulum gereksinimlerini mevcut posta altyapınıza göre değerlendirin.

Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.

Bilgi Merkezi

Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!