Bulutta İş Sürekliliği ve Olağanüstü Durum Kurtarma

İş Sürekliliği ve Felaket Kurtarma (BC/DR), diğer teknolojiler için olduğu kadar bulut bilişim için de önemlidir. Ancak, bulut için belirli hususların akılda tutulması gerekir. Bu blog, bulutta BC/DR'ye nasıl yaklaşılacağına dair bir genel bakış sunacak ve buna, başarısızlık için Mimarlığın kapsayıcı ilkesi ve üç farklı senaryo için dikkate alınacak hususlar da dahil olacak.
 
Bulutta BC/DR'ye Nasıl Yaklaşılır?
 
Güvenlik ve uyumluluk gibi, BC/DR de Ortak bir Sorumluluktur. Bulut sağlayıcısının yönetmesi gereken yönler vardır, ancak bulut müşterisi, bulut hizmetini nasıl kullandıklarından ve yönettiklerinden nihai olarak sorumludur.
 
Ek olarak, BC/DR Riske dayalı bir yaklaşım benimsemelidir. Birçok BC seçeneği, bulutta maliyet açısından engelleyici olabilir, ancak gerekli olmayabilir. Örneğin, büyük bir IaaS sağlayıcısının iflas etme veya tüm iş modelini değiştirme olasılığı düşüktür, ancak bu, girişim destekli daha küçük bir SaaS sağlayıcısı için o kadar da nadir değildir.
 
Başarısızlık Mimarı
Bulut platformları inanılmaz derecede esnek olabilir, ancak tek bulut Varlıkları tipik olarak geleneksel altyapıdan daha az dayanıklıdır. Bunun nedeni, son derece karmaşık ortamlarda çalışan sanallaştırılmış kaynakların doğası gereği daha fazla kırılgan olmasıdır. Bununla birlikte, bu, bulut sağlayıcılarının, genellikle geleneksel altyapıda elde edilebilenin ötesinde, esnekliği artırmak için seçenekler sunma eğiliminde olduğu anlamına gelir. Örneğin, yüksek Erişilebilirlik için fiziksel olarak farklı veri merkezlerini kapsayan otomatik ölçeklendirilmiş bir grup içinde sanal makineleri dağıtabileceğiniz birden çok "bölgeyi" etkinleştirerek esnekliği artırabilirsiniz.
 
Bu ekstra esneklik, yalnızca bu yeteneklerden yararlanmak için Mimarsanız elde edilebilir. Uygulamanızı tek bir bölgede veya hatta tek bir bölgedeki tek bir sanal makinede dağıtmak, büyük olasılıkla tek, iyi bakımlı bir fiziksel sunucuda dağıtmaktan daha az dayanıklı olacaktır.
 
Unutma:
 
Tüm Varlıkların eşit sürekliliğe ihtiyacı yoktur.
Sırf Kontrol kaybı algısı nedeniyle tam sağlayıcı kesintileri planlayarak kendinizi çıldırtmayın. Tarihi performansa bakın.
Geleneksel altyapıdakilere eşdeğer kurtarma süresi hedefleri (RTO'lar) ve kurtarma noktası hedefleri (RPO'lar) tasarlamaya çalışın.
Bulut Sağlayıcı İçinde İş Sürekliliği
Varlıkları buluta dağıttığınızda, bulutun her zaman orada olacağını veya her zaman beklediğiniz gibi çalışacağını varsayamazsınız. Kilit nokta, kaynakları havuzlarda sanallaştırmanın doğasının, sanal makine gibi herhangi bir tek varlık için tipik olarak daha az esneklik oluşturmasıdır. Öte yandan, kaynakları soyutlamak ve her şeyi Yazılım aracılığıyla yönetmek, dayanıklı depolama gibi esneklik özelliklerini daha kolay etkinleştirmek için esneklik sağlar.
 
Burada çok çeşitli seçenekler vardır ve tüm sağlayıcılar veya platformlar eşit yaratılmamıştır, ancak genel bir terim olarak “bulut” un geleneksel altyapıdan az çok esnek olduğunu varsaymamalısınız. Bu nedenle, dağıtımları buluta geçirirken yeniden tasarlamak genellikle en iyisidir.
 
Akılda tutulması gereken bazı noktalar:
 
Üçüncü taraf araçlar aracılığıyla herhangi bir ek yetenek eklemeden önce platformun BC/DR özelliklerini anlayın ve bunlardan yararlanın.
BC/DR, meta yapı, altyapı, bilgi yapısı ve uygulama yapısı dahil olmak üzere tüm mantıksal yığını hesaba katmalıdır.
Gerçek zamanlı geçiş mümkün olmadığında, uygulamanızı hizmet kesintisi durumunda sorunsuz bir şekilde başarısız olacak şekilde tasarlayın. Bunu desteklemek için birçok otomasyon tekniği vardır.
Kesinti süresi her zaman bir seçenektir. Her zaman mükemmel Erişilebilirliğe ihtiyacınız yoktur, ancak bir kesintiyi kabul etmeyi planlıyorsanız, en azından acil durum kesinti bildirim sayfaları ve yanıtlarıyla sorunsuz bir şekilde başarısız olduğunuzdan emin olmalısınız.
Bulut Sağlayıcısının Kaybı için İş Sürekliliği
Bir bulut sağlayıcısının tamamının veya en azından altyapısının büyük bir bölümünün çökmesi her zaman mümkündür. Sağlayıcınızın geçmişine ve dahili Erişilebilirlik özelliklerine bağlı olarak, bu Riski kabul etmek genellikle meşru bir seçenektir. Kesinti süresi başka bir seçenek olabilir, ancak RTO'larınıza bağlıdır. Söz konusu hizmet de aynı sağlayıcıya bağlıysa veya bu sağlayıcıya bağlıysa, ikincil bir sağlayıcı veya hizmet seçme konusunda dikkatli olun.
 
SaaS, sağlayıcıya tamamen bağımlı olması nedeniyle genellikle en büyük sağlayıcı kesintisi endişesi olabilir. Planlanmış veri çıkarma ve arşivleme, kapalı kalma süresini kabul etmenin dışındaki tek BC seçeneğiniz olabilir. Başka bir bulut hizmetine, özellikle de IaaS/PaaS'ye ayıklama ve arşivleme, onu yerel/Şirket İçi depolamaya taşımaktan daha iyi bir seçenek olabilir.
 
Özel Bulut İçin İş Sürekliliği
 
Bu tamamen sağlayıcının omuzlarında. RTO'lar ve RPO'lar katı olmalıdır, çünkü bulut çökerse her şey çöker.
 
Başkalarına hizmet sağlıyorsanız, BC planlarınızı oluştururken veri yerleşimi de dahil olmak üzere sözleşme gereksinimlerinin farkında olun. Örneğin, farklı bir yasal yetki alanında farklı bir coğrafyaya devretmek, sözleşmeleri veya yerel yasaları ihlal edebilir.