Yıkım onarımı nedir?

Yıkım onarımı (DR), bir kuruluş içinde çeşitli iş kolları tarafından geliştirilen ve muhafaza edilen, kapsamlı iş sürekliliği planlarının bir özelliğidir. Etkili bir yıkım onarımı planı, misyon ve iş açısından kritik sistemlerin planlanmamış hatta planlanmış kesintilerinin işletmenin faaliyet gösterme ve gelir elde etmeye devam etme kabiliyetine etkisini azaltır.

Bunun için yıkım onarımı planı kuruluşlara sistemlerini geri yüklemek, yeniden geliştirmek ve yeniden canlandırmak ve daha esnek bir altyapı oluşturmak üzere birleşik ve iş birliğine dayalı bir şekilde çalışmalarını sağlayan esnek bir yapı sağlar.

Yıkım onarımı neden önemlidir?

Bir işletme, ödemeler hesaplanıp ve hesaplar finanse edilmeden hemen önce bordro sistemini kaybederse ne kadar süre çalışabilir? Federal, eyalet ve yerel vergilerin geciken ödemesi nedeniyle bir şirket hangi cezalar alabilir? Şirket, çalışanlara zamanında ödeme yapmamanın ve çalışanların çalışmaya ne kadar devam edeceğinin bir sonucu olarak hangi sonuçlarla karşı karşıya kalabilir?

Yıkım onarımı yapmak mı yapmamak mı? Bu artık bir soru değil. Asıl soru, dakikalar, günler veya haftalarca önemli verileri ve inşa etmesi yıllarca süren güveni bir anda kaybetmenin gerçek maliyeti?

Yıkım onarımı artık düşünülmeden veya yalnızca yeterli bütçe olduğunda dikkate alınan bir şey olarak kalamaz, çünkü bugünün kuruluşlarının yıkıcı olaylara anında yanıt vermeleri ve çalışmaya devam etmeleri beklenir. Kuruluşlar, bir esneklik planını uygulamanın maliyeti nedeniyle caymak yerine daha ayrıntılı bir çalışma yaparak hiçbir planının olmaması durumunun gerçek maliyetini değerlendirmelidir. Örneğin, karşılanamayan hizmet düzeyi anlaşmalarını (SLA'lar) veya bir kesintiden kaynaklanan cezaları ve gelir kaybını inceleyin. Yıkım onarımı uygulama maliyetini cezalar, gelir kaybı ve müşteri güveni kaybıyla karşılaştırdığınızda seçim nettir.

Görüntünün adı "Gelir, üretkenlik ve kaybedilen sadakat." Bu görüntüde gösterilen üç temel istatistik vardır. Bu istatistikler, 2019 yılında IBM adına Forrester Consulting tarafından yapılan bir araştırmadan elde edilmiştir. Ankete katılanlara sorulan soru şuydu: "Kuruluşunuz planlı ve planlanmamış kapalı kalma süreleri nedeniyle aşağıdaki maliyetlerden hangisiyle karşılaşıyor?"
Sol tarafta, görüntülenen istatistik, ankete katılanların %53'ünün "Gelir kaybı" yanıtını verdiğini gösteriyor. Ortadaki istatistik, %47'nin "Kayıp üretkenlik" yanıtını verdiğini gösteriyor. Sağ taraftaki istatistik, %41'inin "Marka özkaynağı veya güven kaybı" yanıtını verdiğini gösteriyor.

Planlanmamış kesintiler

Kesintinin doğal bir afet, BT operatörü/hizmet sağlayıcısı hataları, veri bozulması veya fidye yazılımı saldırıları nedeniyle oluşması fark etmeksizin, bir kuruluşun kendisini yıkıcı kayıplara yol açan, fırsatçı rakiplerin yerine geçmesini sağlayan, itibar ve iyi niyet kaybına neden olan iş operasyonlarındaki kesintilerden koruyabilmesi gerekir.

Bu sonuçlar dramatik görünse de pek çok tanınmış kuruluşun zamanında kurtarılamayan ve büyük miktarda kritik işlemsel verisi müşteri bilgileri ve güven kaybına yol açan yakın zamanlı deneyimlerini yansıtmaktadır.

Çok çeşitli senaryolar ve kök nedenler iş operasyonlarını kesintiye uğratabilir.

Bu görüntünün adı "Planlanmamış kapalı kalma süresinin en önemli nedenleri"dir. Görüntüde, planlanmamış kesintilerin nedenlerini gösteren bir çubuk grafik görüntülenir. Çubuk grafiği üç kategoriye ayrılır: operasyonel başarısızlıklar, doğal afetler ve insan kaynaklı olaylar. Operasyonel başarısızlıklar çubuk grafiğin en solunda gruplanır, doğal afetler ortadadır ve insan kaynaklı olaylar çubuk grafiğin en sağında gruplanır. Bu grafiğin kaynağı Forrester Research, Inc.'dir

Planlı kesintiler

Bulut ortamında yıkım onarımı hizmeti (DRaaS) kuruluşlara operasyonel esneklik için benzersiz seçenekler sağlar. Kuruluşlar, yıkıcı olaylardan kurtulmaktan daha sık olarak planlanan kesintiler için olağanüstü yıkım onarımı çözümlerini kullanır.

Tipik sorun noktaları

• Yıkım onarımı için geleneksel yaklaşımlar otomasyona yatırım yapılmasını gerektirir.
• Katman 1 veri depolama merkezlerindeki iş sistemleri bile, çok sık olan elektrik kesintilerinden etkilenebilir. Elektrik kesintisi gibi yaygın bir olayın bir veya iki günlük verimlilik kaybına neden olma sıklığı nedir? BT personeli, durdurma çözümlerini kullanarak sistemleri çalışır duruma getirmek için konferans çağrılarında saatler veya günler harcıyor. • Bazı şirketler, yıkım onarımını yönetmek için şirket içi otomasyon geliştiren BT bütçelerinin önemli bir bölümünü yalnızca yıkım onarımı kullanma korkusuna karşılık harcıyor ve hatta beklendiği gibi çalışmaya devam etmesini sağlamak için periyodik olarak test ediyor. • Planlı bir bakım döneminden kurtulmak genellikle bir gün (veya günler) sürer. • İyi belgelenmiş yıkım onarımı planları veya işletim kitapları bile günlere yayılan kayıp üretkenliği içerebilirken, BT operasyon personeli bir şeyleri tekrar çalıştırmak için kahramanlık eylemleri gerçekleştirir.

Yıkım onarımı için temel hedefler

Yıkım onarımının iki temel amacı, etkilenen sistemleri mümkün olan en hızlı şekilde çalışır duruma döndürmek ve bunu yıkıcı bir olaydan veya planlı bir kesintiden sonra mümkün olan en az veri kaybı ile yapmaktır. Bu iki temel hedefin metrikleri, sırasıyla kurtarma zamanı hedefi (RTO) ve kurtarma noktası hedefi (RPO) olarak herkes tarafından bilinir.

Her iş sisteminin, BT operasyonları ve iş sahipleri arasındaki hizmet düzeyi anlaşmasına bağlı olarak bu iki metrik için farklı gereksinimleri olacaktır.

Görüntünün adı "Veri koruma terminolojisi"dir. Veri kaybı toleransı ve kapalı kalma süresi toleransı, görüntünün merkezinden ters yönlerde uzanan düz bir çizgide gösterilmektedir. Solda "Veri kaybı" ve sağda "Kapalı Kalma Süresi" yer almaktadır.

Kurtarma süresi hedefi

Kurtarma süresi hedefi, bir iş sistemini planlı veya planlanmamış kesintilerden sonra tamamen çalışır bir duruma geri yüklemek için gereken süredir.

Kurtarma noktası hedefi

Kurtarma noktası hedefi, belirli bir iş sistemine zarar vermeden önce kaybedilebilecek maksimum veri miktarıdır. RPO genellikle son veri yedekleme, çoğaltma veya anlık görüntüsünden itibaren ölçülür.

Yıkım onarımı ve yüksek erişilebilirlik karşılaştırması

Geleneksel olarak yüksek erişilebilirlik (HA) tek hata noktalarına karşı koruma sağlarken yıkım onarımı birden fazla hata noktasına karşı koruma sağlar. Bulut bilişimde güç, soğutma, depolama, ağlar ve fiziksel sunucular dahil olmak üzere fiziksel altyapı katmanındaki tek hata noktalarına karşı koruma, erişilebilirlik ve hata etki alanları aracılığıyla tamamen genel mimariden bağımsız hale getirilir.

Bu durumda yüksek erişilebilirlik, ölçeklenebilirdir ve veri kaybına veya işleme performansının kaybına son derece dayanıklıdır. Neredeyse her kurumsal sınıf bulut sağlayıcısı, tekliflerinde yüksek erişilebilirlik sağlar.

Veritabanları için sıfır veri kaybı ve sıfır kapalı kalma süresi koruması sağlayan yüksek erişilebilirlik yıkım onarımı çözümleri, karmaşık veri eşleme ve çoğaltma teknolojisi söz konusu olduğunda pahalı olur. Bu çözümler, belirli bir noktaya ait kurtarma noktası hedefi ve sabit depolama ile kapsamlı bir yedekleme aracılığıyla elde edilen fidye yazılımı koruması sağlamaz.

Geleneksel yüksek erişilebilirlik çözümleri, düşük maliyetli bulutta yıkım onarımı (CDR) çözümü ile birlikte iyi performans gösterir. Eklenti CDR teknolojisi, sıfır veri kaybı, sıfır kapalı kalma süresi ve uzun vadeli artımlı geri alma işlemleriyle fidye yazılımı koruması gerektiren veritabanları için ek bir koruma katmanı sağlar.

Kaynak konumdaki ve sabit hedef veri merkezi konumundaki BT altyapısını kopyalamanın yüksek maliyeti nedeniyle şirket içi yıkım onarımı, esnek olmayan ve pahalı bir çözümdür. WAN üzerinden çalışamaz veya sunucuları farklı ortamlar arasında geçiremez. Bu nedenle, kaynak ve hedef veri merkezleri arasında özel bir devrenin tek bir birbirine bağlı LAN ortamı gibi çalışmasını gerektirir. Geleneksel yıkım onarımı aynı zamanda şirket içi ortam ve bulut platformu ya da iki farklı bulut platformu gibi farklı heterojen ortamlar arasındaki sunucuların geçişini yapamaz.

DRaaS sıkı bir şekilde kontrol edilen ve son derece spesifik bir ortam oluşturmak için satıcı tarafından sağlanan yedekleme çözümlerinin ve açık kaynaklı geçiş araçlarının bir yamasını kullanır. Son kullanıcı sadece DRaaS sağlayıcısının geleneksel barındırma ortamındaki iş yüklerini şirket içi VMware ortamlarından kurtarabilir. Bu satıcı tarafından sağlanan çözümler, koruyabilecekleri iş yükü aralığında ve destekleyebilecekleri hesaplama ortamlarında pahalı ve sınırlı olabilir.

Yıkım onarımı iş akışları, işletim kitapları ve planlar

Oracle, tipik olarak bir yıkım onarımı planı olan yıkım onarımı iş akışını ifade eder. Yıkım onarımı planı veya işletim kitabı; hesaplama örneği, platform, veritabanı ve uygulama yazılımlarını bulutta önceden belirlenmiş bir kurtarma bölgesine geçirmek için tamamlanması gereken önceden belirlenmiş adımların veya görevlerin listesidir. Bunlara tüm görevler veya rol devri ya da yük devri gibi bir yıkım onarımı işlemi sırasında bir insan veya bir tür otomasyon tarafından yürütülen ayrı adımlar dahildir. Yıkım onarımı planı, yıkım onarımı işletim kitabı ve yıkım onarımı iş akışı terimleri birbirinin yerine kullanılabilir.

Yıkım onarımı işlemleri (geçiş ve hata durumunda yük devri karşılaştırması)

Yıkım onarımı işlemi, altyapıyı, veritabanını ve uygulama yazılımlarını tamamen çalışır durumda geri yüklemek için gerekli olan yıkım onarımı planındaki önceden belirlenmiş her bir adımı veya görevi yürütme sürecidir. Uygulama yazılımı yığınının farklı bir konuma geçişini açıklamak için iki farklı terim kullanılır: hata durumunda yük devri ve geçiş.

Hata Durumunda Yük Devri

Hata durumunda yük devri, uygulama yazılımlarının, veritabanlarının ve sanal makinelerin çöktüğü ve depolama, veri ve konuk işletim sistemleri dahil olmak üzere tüm kaynakların tutarsız bir durumda olduğu planlanmamış bir kesintidir. Bu durumda, birincil bulut bölgesinin tamamen erişilemez olduğu ve kullanılamayacağı varsayılır. Bu da gerçek bir yıkım onarımı işleminin tetiklenmesi gerektiğini gösterir.

Bu nedenle bir yıkım onarımı planındaki tüm yıkım onarımı görevleri yalnızca hazır bekleyen bulut bölgesinde gerçekleştirilebilir. Bulut sağlayıcısının DRaaS çözümünün, yıkıcı bir yıkım yaşandığında erişilebilir ve işlevsel olduğundan emin olmak için hazır bekleyen bölgede yüksek erişilebilirlik sağlayacak şekilde tasarlanması çok önemlidir.

Geçiş

Geçiş, uygulamaların, veritabanlarının ve sanal makinelerin veya sunucuların düzenli olarak kapatılmasını içeren planlı kapalı kalma süresine işaret eder. Bu durumda hem birincil hem de hazır bekleyen bölgeler normal şekilde çalışır ve BT operasyon personeli bakım veya sürekli yükseltmelerin tamamlanması için bir bölgeden diğerine bir veya daha fazla sistemi "taşıma" konusuna odaklanabilir.

Bulut dağıtım stratejisi

Modern kuruluşlar; maliyet, performans ve iş sürekliliği gereksinimleri dahil olmak üzere çeşitli nedenlerle aşağıdaki bulut dağıtım modellerinden biri veya daha fazlasından yararlanabilir. Şirketler operasyonları buluta taşımaya devam ettikçe, güçlü bir bulut dağıtım stratejisi gittikçe daha yaygın hale gelir.

Bölgeler arası yıkım onarımı çözümleri

Bölgeler arası yıkım onarımı çözümleri, kuruluşları tek bir bulut sağlayıcısının bulut altyapısında barındırılan iş sistemlerine erişimi etkileyecek tam kesintilerden korur. Adından da anlaşılacağı gibi, sanal makineler, veritabanları ve uygulama yazılımları dahil olmak üzere belirli bir iş sistemine yönelik tüm uygulama yığını talebe bağlı olarak farklı bir coğrafi konumdaki tümüyle farklı bir bulut bölgesine geçirilebilir.

DRaaS çözümleri, insan kaynakları portalı, finansal servisler portalı veya kurumsal kaynak yönetimi uygulaması gibi bir kurumsal sistemin tamamını tamamen farklı bir bulut bölgesine taşıyabilmelidir. DRaaS, her bir uygulama yazılımı için hizmet düzeyi anlaşmalarının gerektirdiği kurtarma zamanı ve kurtarma noktası hedeflerini karşılayabilmelidir.

Oracle Cloud Infrastructure (OCI) Full Stack Disaster Recovery gibi bölgeler arası yıkım onarımı çözümleri, tüm kurumsal uygulama yazılımlarını, o bölgedeki tüm erişilebilirlik etki alanlarının kaybı da dahil olmak üzere tüm bulut bölgesine erişimin felaketle kaybedilmesinden korur.

Hibrit bulut yıkım onarımı çözümleri

Hibrit bulut yıkım onarımı, şirketlerin iş yüklerini ve sanal makineleri kendi veri depolama merkezlerinden bulut altyapısına geçirmesine olanak tanıyan çok tercih edilen bir çözümdür. Hibrit bulut, genellikle bir şirketin kritik iş sistemlerinin verilerini ve uygulanabilirliğini korumak için yıkım onarımı çözümü olarak kullanılır.

Oracle müşterileri için hibrit bulut, OCI ve fiziksel sunucular, Oracle bulut araçları veya bir şirketin fiziksel veri depolama merkezindeki diğer sistemler arasında açık bir birliktir. Oracle Private Cloud Appliance X9-2 ve Oracle Exadata Cloud@Customer gibi Oracle bulut cihazları, OCI ile güzel bir entegrasyon sağlayan şirket içi sistemlere yönelik mükemmel örneklerdir.

Oracle iş ortakları tarafından sağlanan Rackware gibi bazı ürünler, şirket içi altyapı ve OCI arasında yıkım onarımı elde etmek için kullanılabilir. Rackware'e Oracle Cloud Marketplace üzerinden erişilebilir.

Çoklu bulut yıkım onarımı çözümleri

Çoklu bulut yıkım onarımı çözümleri, bir uygulama yığınının çeşitli bileşenlerini iki veya daha fazla bulut sağlayıcısının bulut altyapılarına yayarak uygulama yazılımlarını ve verileri korur. Oracle'ın Microsoft Azure ile iş ortaklığı, çoklu bulut ilişkisine iyi bir örnektir.

Yıkım onarımı hizmeti, bölgeler arası yıkım onarımı, hibrit bulut yıkım onarımı ve çoklu bulut yıkım onarımı sağlayabilmelidir. OCI şu anda bölgeler arası yıkım onarımı ve hibrit bulut yıkım onarımı için DRaaS sağlayabilir.

Veritabanları için veri tutarlılığı

Veritabanlarını içeren uygulanabilir yıkım onarımı çözümleri, her zaman veri tutarlılığını sağlama araçlarını içermelidir. Devam eden işlemler dahil olmak üzere bir veritabanının tam veri tutarlılığına kurtarılabileceği nokta, kurtarma noktası hedefini tanımlar.

Veri tutarlılığı, sunucusuz veya düz dosya veritabanları için çok daha az sorundur ancak Oracle Database veya MySQL gibi karmaşık ilişkisel veritabanlarının belirli bir süre boyunca tutarlı bir veri durumuna kurtarılması çok karmaşık olsa da hâlâ çok önemlidir.

MySQL veritabanları için yıkım onarımı konuları

MySQL Database Service'i OCI'de kullanırken, MySQL veritabanı sistemi bir veya daha fazla MySQL örneği için mantıksal bir kapsayıcıdır. Sağlama, otomatik yedekleme ve belirli bir noktaya kurtarma gibi görevlerin yönetilmesini sağlayan bir arayüz sağlar.

MySQL ikili günlük ve yerel çoğaltma teknolojileri, belirli bir noktaya kurtarma, yüksek erişilebilirlik ve yıkım onarımı sağlar. MySQL Grup Çoğaltma genellikle yüksek erişilebilirlik için yerel hata toleranslı kümeler oluşturmak amacıyla kullanılırken MySQL zaman uyumsuz çoğaltma genellikle coğrafi dağıtılmış yıkım onarımı için kullanılır.

Yüksek erişilebilirlik özellikli bir veritabanı sisteminde farklı erişilebilirlik etki alanlarına veya hata etki alanlarına yerleştirilen üç MySQL örneği bulunur. Veritabanı sistemi, bir örnek arızalanırsa sıfır veri kaybı ve minimum kapalı kalma süresi ile başka bir örneğin devralmasını garanti eder. Farklı bölgelerde yıkım onarımı için, iki veritabanı sistemi arasındaki gelen çoğaltma kanalları da oluşturulabilir.

Bulut ortamında MySQL için yıkım onarımı hakkında daha fazla bilgi edinmek üzere aşağıdaki bağlantıları kullanın.

• MySQL için iş sürekliliğine genel bakış
• MySQL için yüksek erişilebilirliğe genel bakış
• MySQL için gelen çoğaltmaya genel bakış

Oracle veritabanları için yıkım onarımı konuları

Oracle Maximum Availability Architecture (MAA), Oracle veritabanları için mimari, konfigürasyon ve yaşam döngüsü en iyi uygulamalarını sunarak şirket içi, bulut veya hibrit konfigürasyonlarda bulunan veritabanları için yüksek erişilebilirlik hizmet düzeylerine olanak tanır.

Bulutta yıkım onarımı için Oracle Maximum Availability Architecture hakkında daha fazla bilgi edinmek üzere aşağıdaki bağlantıları kullanın.

• Oracle Maximum Availability Architecture giriş sayfası
• Oracle Maximum Availability Architecture referans mimarileri
• Oracle Maximum Availability Architecture Oracle Fusion Middleware için en iyi uygulamalar
• Oracle Maximum Availability Architecture uygulama yazılımları için en iyi uygulamalar

Bulut tabanlı dağıtım mimarileri

Dağıtım mimarisi, hesaplama, platform/veritabanı ve uygulama yazılımları gibi çeşitli bileşenlerin, bulut bölgeleri arasında nasıl dağıtıldığını ve böylece bir veri depolama merkezinin toplam hatasından kurtulmanın esnek bir yolunu oluşturduğunu açıklar. Dağıtım mimarisi, bir uygulama grubunun normal çalışmasında her şeyin yer aldığını ve bir şeylerin tekrar çalışması için hazır bekleyen bölgede nelerin kurtarılması gerektiğini açıklar.

Oracle, DRaaS çözümlerinin, her benzersiz iş sistemi için ayrı hizmet düzeyi gereksinimlerini karşılamak üzere yıkım onarımı dağıtım mimarilerinin herhangi bir kombinasyonunu dahil etme esnekliğine sahip olması gerektiğine inanır. Bulut sağlayıcıları, kuruluşların genellikle desteklediği çok çeşitli iş sistemlerinde SLA'ları karşılamak için müşterilerine "yukarıdakilerin tümü" çözümlerini seçme özgürlüğü sunmalıdır.

Yıkım onarımı stratejilerini ve dağıtım mimarilerini tanımlamak için birçok terim kullanılır. Ancak, altyapı, platform ve yıkım onarımı için uygulama yazılımlarının nasıl dağıtılacağını açıklayan çeşitli yaklaşım ve düzenler iki geniş stratejik kategoriye ayrılır: etkin/etkin ve etkin/beklemeli yıkım onarımı.

Aşağıdaki tablo, iki geniş yıkım onarımı stratejisinin kapsamındaki farklı dağıtım mimarilerini tanımlamak için kullanılan genel terimleri özetlemektedir.

Strateji	Dağıtım mimarisi	RPO	RTO
Etkin/beklemeli	Sabit bekleme	Saat	Saat
Etkin/beklemeli	Pilot ışık	Dakika	Saat
Etkin/beklemeli	Normal bekleme	Saniye	Saat
Etkin/beklemeli	Dinamik bekleme	Saniye	Dakika
Etkin/etkin	Etkin/etkin	Sıfıra yakın	Sıfıra yakın

Bu bölüm, yıkım onarımı için etkin/etkin ve etkin/beklemeli yaklaşımlarının bazı varyasyonlarını açıklamaya yöneliktir. Her iki yıkım onarımı stratejisi de iş sürekliliği sağlamak için hazırda tutulur.

Etkin/beklemeli dağıtım mimarileri

Etkin/beklemeli dağıtım mimarilerinin pek çok çeşidi vardır. Bazen etkin/pasif dağıtımlar olarak adlandırılan aktif/beklemeli dağıtımlar genellikle pilot ışık, sabit, normal ve dinamik bekleme dağıtımları olarak bulunur.

Pilot ışık, sabit bekleme, normal bekleme ve dinamik bekleme senaryoları, bir uygulama yazılımı yığınının %100'ünün birincil bölgede çalışırken aynı iş sisteminin %100'ünden azının bekleme bölgesinde etkin olarak çalıştığı aynı temanın bir biçimini temsil eder.

Aşağıdaki çok yüksek düzey kavramsal diyagram serisinin, yaygın dağıtım mimarileri arasındaki bazı temel farklılıkları göstermesi amaçlanır ve referans mimarileri olarak görülmemelidir. Bir uygulama yazılımı yığını için yıkım onarımının nasıl uygulanacağını açıklamamaktadır.

Sabit bekleme

Bu senaryoda, sanal makineler (VM'ler), veritabanı ve uygulama yazılımları yalnızca geçerli birincil bölgede mevcuttur. Önyükleme diskini ve her bir VM için diğer sanal diskleri içeren dosya ve blok depolama birimi grupları bekleme bölgesinde çoğaltılır.

Solda birincil bölgeyi ve sağda bekleme bölgesini içeren bir resim gösterilir. Birincil bölgede üç blok vardır: Her biri ilgili simgeleriyle uygulama yazılımı, veritabanı ve altyapı. Her iki bölgenin de en üstte bir yük dengeleyiciyi temsil eden bir simgesi vardır. Bekleme bölgesindeki yük dengeleyici simgesi, birincil bölgedekinden daha hafif bir gölgedir. Bekleme bölgesinde üç blok vardır: uygulama yazılımı, veritabanı ve altyapı. Bekleme bölgesinde, her biri nesne depolama, blok depolama ve dosya depolama için olmak üzere sadece altyapı bloğu simgelerle doldurulur. Bekleme bölgesindeki veritabanı ve uygulama yazılımı blokları boştur. İki altyapı bloğu arasında nesne depolama çoğaltmasını ve depolama çoğaltmasını temsil eden iki ok gösterilir. Bu oklar birincil bölgeden bekleme bölgesine çoğaltmayı temsil eder.

Geçiş veya hata durumunda yük devri gibi yıkım onarımı işlemleri sırasında, bekleme bölgesinde aynı sanal makineleri içeren çoğaltılmış depolama etkinleştirilir ve aynı sanal makineler durduruldukları veya çöktükleri noktada yeniden başlatılır. Sanal makineler, daha önce etkin bölgede çalışan aynı tam sanal makinelerdir.

Bu dağıtım mimarisi; daha düşük dağıtım maliyetleri, daha düşük bakım genel giderleri ve daha düşük işletim maliyetleri dahil olmak üzere çeşitli avantajlara sahiptir. Ancak, veri tutarlılığını sağlamanın tek yolu düzenli aralıklarla sabit yedeklemeler yapmak olduğundan, arka uç için ilişkisel veritabanlarına güvenen uygulama yazılımları için bu en iyi çözüm olmayabilir. Bu yaklaşım, ara sıra kısa ve tam kesintileri tolere edebilen uygulama yazılımları için uygundur.

Çoğu BT işlemi, veritabanını düzenli olarak kapatarak, blok depolamanın anlık görüntüsünü alarak ve normal işlemleri sürdürerek bu sorunu çözer. Bu, yedeklemenin tamamlandığı ana geri yükleyebileceğiniz için kurtarma noktası hedefini tanımlar.

Bu mimari biraz daha uzun bir kurtarma süresine sahip olacaktır. Veri kaybı riski daha yüksektir, ancak doğru iş yükü için uygulanabilir bir çözümdür. Örneğin, bu çözüm düz dosya veritabanına, sunucusuz veritabanına sahip veya veritabanına olmayan ya da daha fazla esneklik için bölgeler arasında sanal makine kümesi oluşturmak isteyen müşteriler için mükemmel bir çözüm olabilir.

Bu dağıtım mimarisi için örnek yıkım onarımı iş akışları

Aşağıdaki iki senaryo, sabit bekleme dağıtımlarına yönelik yıkım onarımı işlemleri için işlem akışının nasıl ilerleyebileceğini açıklar.

Geçiş durumunda aşağıdaki görevler hem birincil hem de bekleme bölgelerinde gerçekleştirilir:

• Birincil uygulama yazılımları durdurulur.
• Birincil veritabanları durdurulur ve bekleme bölgesiyle senkronize edilir.
• Birincil sanal makineler sorunsuz şekilde durdurulur.
• Birincil depolama, bekleme bölgesiyle senkronize edilir.
• Çoğaltılan depolama alanı çevrimiçi hale getirilir, çoğaltma işlemi tersine çevrilir ve artık bekleme bölgesinde birincil durumdadır.
• Birincil sanal makinelerin çoğaltılmış kopyaları başlatılır, uygulama yazılımı yığınının gerektirdiği tüm sistem uygulama yazılımları veya araçları başlatılır ve artık bekleme bölgesinde birincil durumdadır.
• Birincil veritabanlarının çoğaltılmış kopyaları, bekleme bölgesinde en son sabit yedekleme veya işlem kullanılarak ve çoğaltılan depolama alanından tekrarlama günlükleri kullanılarak kurtarılır.
• Birincil veritabanlarının çoğaltılmış kopyaları başlatılıp kullanıma sunulur ve artık bekleme bölgesinde birincil durumdadır
• Birincil uygulama yazılımlarının çoğaltılmış kopyaları başlatılıp doğrulanır ve artık bekleme bölgesinde birincil durumdadır.
• DNS ve yük dengeleyicilerde yapılan tüm değişiklikler, genele açık ağ üzerinden uygulama yazılımına erişim sağlamak için yapılır.

Hata durumunda yük devri durumunda aşağıdaki görevler sadece bekleme bölgesinde gerçekleştirilir:

• Çoğaltılan depolama alanı çevrimiçi hale getirilir, çoğaltma işlemi tersine çevrilir ve artık bekleme bölgesinde birincil durumdadır.
• Birincil sanal makinelerin çoğaltılmış kopyaları başlatılır, uygulama yazılımı yığınının gerektirdiği tüm sistem uygulama yazılımları veya araçları başlatılır ve artık bekleme bölgesinde birincil durumdadır.
• Birincil veritabanlarının çoğaltılmış kopyaları, bekleme bölgesinde en son sabit yedekleme veya işlem kullanılarak ve çoğaltılan depolama alanından tekrarlama günlükleri kullanılarak kurtarılır.
• Birincil veritabanlarının çoğaltılmış kopyaları başlatılıp kullanıma sunulur ve artık bekleme bölgesinde birincil durumdadır
• Birincil uygulama yazılımlarının çoğaltılmış kopyaları başlatılıp doğrulanır ve artık bekleme bölgesinde birincil durumdadır.
• DNS ve yük dengeleyicilerde yapılan tüm değişiklikler, genele açık ağ üzerinden uygulama yazılımına erişim sağlamak için yapılır.

Normal bekleme

Bu senaryoda, sanal makineler hem birincil hem de yedek bölgelerde bulunur ancak birbirlerinden tamamen bağımsızdır ve kendi benzersiz ana bilgisayar adlarına ve önceden atanmış IP adreslerine sahiptir. Bekleme bölgesinde sanal makineler mevcuttur ve bunlar müşteri tercihine bağlı olarak durdurulabilir veya çalıştırılabilir.

Solda birincil bölgeyi ve sağda bekleme bölgesini içeren bir resim gösterilir. Birincil bölgede üç blok vardır: Her biri ilgili simgeleriyle uygulama yazılımı, veritabanı ve altyapı. Her iki bölgenin de en üstte bir yük dengeleyiciyi temsil eden bir simgesi vardır. Bekleme bölgesindeki yük dengeleyici simgesi, birincil bölgedekinden daha hafif bir gölgedir. Bekleme bölgesinde üç blok vardır: uygulama yazılımı, veritabanı ve altyapı. Bekleme bölgesinde, her biri nesne depolama, blok depolama ve dosya depolama için olmak üzere altyapı bloğu simgelerle doldurulur. Altyapı düzeyinde sanal makineler için de bir simge bulunur ancak daha hafif bir gölgedir. Bekleme bölgesindeki veritabanı simgeleri ve uygulama yazılımı simgesi de daha hafif bir gölgedir. İki altyapı bloğu arasında nesne depolama çoğaltmasını ve depolama çoğaltmasını temsil eden iki ok gösterilir. Bu oklar birincil bölgeden bekleme bölgesine çoğaltmayı temsil eder.

Veritabanları birincil bölgede ve bekleme bölgesinde çalıştırılmalıdır.

Oracle veritabanlarında, birincil ve bekleme veritabanını çoğaltmak için Oracle Data Guard kullanmanızı öneririz. Daha ayrıntılı bilgi için Gold MAA referans mimarimize bakın.

Oracle dışı veritabanları için ilgili yerel çoğaltma teknolojileri, veritabanlarının birincil ve bekleme bölgeleri arasında senkronize olmasını sağlamak için kullanılır.

Ayrıca uygulama yazılımları bekleme bulut bölgesinde de mevcuttur ancak çalışır veya erişilebilir durumda değildir.

Bu dağıtım mimarisi için örnek yıkım onarımı iş akışları

Aşağıdaki iki senaryo, normal bekleme dağıtımlarına yönelik yıkım onarımı işlemleri için işlem akışının nasıl ilerleyebileceğini açıklar.

Geçiş durumunda aşağıdaki görevler hem birincil hem de bekleme bölgelerinde gerçekleştirilir:

• Birincil uygulama yazılımları durdurulur.
• Birincil veritabanları durdurulur ve bekleme bölgesiyle senkronize edilir.
• Birincil sanal makineler sorunsuz şekilde durdurulur.
• Birincil depolama, bekleme bölgesiyle senkronize edilir.
• Çoğaltılan depolama alanı çevrimiçi hale getirilir, çoğaltma işlemi tersine çevrilir ve artık bekleme bölgesinde birincil durumdadır.
• Halihazırda çalışmıyorsa bekleme sanal makineleri başlatılır, uygulama yazılımı yığınının gerektirdiği tüm sistem uygulama yazılımları veya araçları başlatılır ve artık bekleme bölgesinde birincil durumdadır.
• Bekleme veritabanları tam okuma/yazma erişimine geçirilir ve artık bekleme bölgesinde birincil durumdadır.
• Bekleme uygulama yazılımları başlatılıp doğrulanır ve artık bekleme bölgesinde birincil durumdadır.
• DNS ve yük dengeleyicilerde yapılan tüm değişiklikler, genele açık ağ üzerinden uygulama yazılımına erişim sağlamak için yapılır.

Hata durumunda yük devri durumunda aşağıdaki görevler sadece bekleme bölgesinde gerçekleştirilir:

• Çoğaltılan depolama alanı çevrimiçi hale getirilir, mümkünse çoğaltma işlemi tersine çevrilir ve bekleme bölgesinde birincil durumdadır.
• Halihazırda çalışmıyorsa bekleme sanal makineleri başlatılır, uygulama yazılımı yığınının gerektirdiği tüm sistem uygulama yazılımları veya araçları başlatılır ve artık bekleme bölgesinde birincil durumdadır.
• Bekleme veritabanları en son işlem kullanılarak kurtarılır ve günlükleri çoğaltılmış depolama alanından tekrarlanır.
• Bekleme veritabanları tam okuma/yazma erişimine geçirilir ve artık bekleme bölgesinde birincil durumdadır.
• Bekleme uygulama yazılımları başlatılıp doğrulanır ve artık bekleme bölgesinde birincil durumdadır.
• DNS ve yük dengeleyicilerde yapılan tüm değişiklikler, genele açık ağ üzerinden uygulama yazılımına erişim sağlamak için yapılır.

Dinamik bekleme

Bu senaryoda, sanal makineler mevcuttur ve kendi benzersiz ana bilgisayar adları ve önceden atanmış IP adresleri ile hem birincil bölgelerde hem de bekleme bölgelerinde çalışır.

Solda birincil bölgeyi ve sağda bekleme bölgesini içeren bir resim gösterilir. Birincil bölgede üç blok vardır: Her biri ilgili simgeleriyle uygulama yazılımı, veritabanı ve altyapı. Her iki bölgenin de en üstte bir yük dengeleyiciyi temsil eden bir simgesi vardır. Bekleme bölgesindeki yük dengeleyici simgesi, birincil bölgedekinden daha hafif bir gölgedir. Bekleme bölgesinde üç blok vardır: uygulama yazılımı, veritabanı ve altyapı. Hem birincil hem de bekleme bölgelerinin uygulama yazılımı, veritabanı ve altyapı bloklarında simgeleri vardır. Altyapı bloğunda hem birincil hem de bekleme bölgelerinde sanal makineler, dosya depolama, nesne depolama ve blok depolama simgeleri vardır. Yalnızca bekleme bölgesindeki veritabanı simgeleri daha hafif bir gölgedir. İki altyapı bloğu arasında nesne depolama çoğaltmasını ve depolama çoğaltmasını temsil eden iki ok gösterilir. Bu oklar birincil bölgeden bekleme bölgesine çoğaltmayı temsil eder.

Veritabanları birincil bölgede ve bekleme bölgesinde çalıştırılmalıdır.

Oracle veritabanlarında, birincil ve bekleme veritabanını çoğaltmak için Oracle Data Guard kullanmanızı öneririz. Daha ayrıntılı bilgi için Gold MAA referans mimarimize bakın.

Oracle dışı veritabanları için ilgili yerel çoğaltma teknolojileri, veritabanlarının birincil ve bekleme bölgeleri arasında senkronize olmasını sağlamak için kullanılır.

Uygulama yazılımları bekleme bulut bölgesinde çalışır ancak bunlara herkese açık ağ üzerinden erişilemez.

Bu dağıtım mimarisi için örnek yıkım onarımı iş akışları

Aşağıdaki iki senaryo, dinamik bekleme dağıtımlarına yönelik yıkım onarımı işlemleri için işlem akışının nasıl ilerleyebileceğini açıklar.

Geçiş durumunda aşağıdaki görevler hem birincil hem de bekleme bölgelerinde gerçekleştirilir:

• Birincil uygulama yazılımları durdurulur.
• Birincil veritabanları durdurulur ve bekleme bölgesiyle senkronize edilir.
• Birincil sanal makineler sorunsuz şekilde durdurulur.
• Birincil depolama, bekleme bölgesiyle senkronize edilir.
• Çoğaltılan depolama alanı çevrimiçi hale getirilir, çoğaltma işlemi tersine çevrilir ve artık bekleme bölgesinde birincil durumdadır.
• Bekleme sanal makineleri zaten çalışıyordur, uygulama yazılımı yığınının gerektirdiği tüm sistem uygulama yazılımları veya araçları başlatılır ve artık bekleme bölgesinde birincil durumdadır.
• Bekleme veritabanları tam okuma/yazma erişimine geçirilir ve artık bekleme bölgesinde birincil durumdadır.
• Bekleme uygulama yazılımları başlatılıp doğrulanır ve artık bekleme bölgesinde birincil durumdadır.
• DNS ve yük dengeleyicilerde yapılan tüm değişiklikler, genele açık ağ üzerinden uygulama yazılımına erişim sağlamak için yapılır.

Hata durumunda yük devri durumunda aşağıdaki görevler sadece bekleme bölgesinde gerçekleştirilir:

• Çoğaltılan depolama alanı çevrimiçi hale getirilir, mümkünse çoğaltma işlemi tersine çevrilir ve bekleme bölgesinde birincil durumdadır.
• Halihazırda çalışmıyorsa bekleme sanal makineleri başlatılır, uygulama yazılımı yığınının gerektirdiği tüm sistem uygulama yazılımları veya araçları başlatılır ve artık bekleme bölgesinde birincil durumdadır.
• Bekleme veritabanları en son işlem kullanılarak kurtarılır ve günlükleri çoğaltılmış depolama alanından tekrarlanır.
• Bekleme veritabanları tam okuma/yazma erişimine geçirilir ve artık bekleme bölgesinde birincil durumdadır.
• Bekleme uygulama yazılımları başlatılıp doğrulanır ve artık bekleme bölgesinde birincil durumdadır.
• DNS ve yük dengeleyicilerde yapılan tüm değişiklikler, genele açık ağ üzerinden uygulama yazılımına erişim sağlamak için yapılır.

Etkin/etkin dağıtım mimarisi

Bu senaryoda tüm uygulama yazılımı yığını tamamen çalışır durumdadır ve hem birincil hem de bekleme bölgelerinde bir iş yükünü işler.

Solda birincil bölgeyi ve sağda bekleme bölgesini içeren bir resim gösterilir. Birincil bölgede ve bekleme bölgesinde üç blok vardır: Her biri ilgili simgeleriyle uygulama yazılımı, veritabanı ve altyapı. Her iki bölgenin de en üstte bir yük dengeleyiciyi temsil eden bir simgesi vardır. Hiçbiri gri değildir. Hem birincil hem de bekleme bölgelerindeki uygulama yazılımı, veritabanı ve altyapı bloklarındaki simgeler renkli gösterilir. İki altyapı bloğu arasında isteğe bağlı depolama çoğaltmasını temsil eden bir ok gösterilir. Bu ok birincil bölgeden bekleme bölgesine çoğaltmayı temsil eder.

Veritabanları birincil bölgede ve bekleme bölgesinde çalıştırılmalıdır.

Oracle veritabanları için etkin/etkin uygulama konfigürasyonuna sahip olmak üzere Oracle GoldenGate kullanmanızı öneririz. Bunun dışında, sıfıra yakın bir RTO ve RPO elde etmek için her bölgede Oracle Data Guard kullanarak yerel bekleme veritabanlarına tutmanızı öneririz. Daha ayrıntılı bilgi için Platinum MAA referans mimarimize bakın.

Oracle dışı veritabanları için ilgili yerel çoğaltma ve etkin/etkin teknolojileri, veritabanlarının birincil ve bekleme bölgeleri arasında senkronize olmasını sağlamak için kullanılır.

Uygulama yazılımları, bekleme bulut bölgesindeki genel ağ üzerinden çalışır ve erişilebilir durumdadır, ayrıca çalışan bir iş yüküne sahiptir.

DRaaS ile yıkım onarımı görevlerini otomatikleştirme

Oracle ekipleri, Oracle'ın kurumsal sınıf veritabanlarının ve uygulama yazılımlarının büyük çoğunluğu da dâhil olmak üzere ürünlerine yüksek erişilebilirlik sağlamak amacıyla büyük çaba harcadı. Geleneksel işletme içi ayarlarda ve bulut ortamında yıkım onarımı için genellikle en iyi uygulamaları ve dağıtım mimarilerini tasarladılar. Her ürün serisi, uygulama yazılımlarını desteklemek için gereken tüm bileşenleri kurtarmak için ayrı bağlantılı adımlar içeren bağımsız uygulama yazılımları için bir yıkım onarımı yaklaşımı ortaya koyar.

Bulut tabanlı yıkım onarımı hizmeti, geliştiriciler, bulut mimarları ve ürün çözümü mimarları tarafından tasarlanan tüm ayrı bağlantılı adımları tek bir tıklamayla başlatılabilen tek bir iş akışına bağlayabilir. OCI; esnek, yüksek düzeyde ölçeklenebilir ve son derece genişletilebilir olan Full Stack Disaster Recovery adlı DRaaS çözümü sunar.

OCI Full Stack Disaster Recovery, tek bir tıklamayla dünyanın her yerinden OCI bölgeleri arasında altyapı, veritabanı ve uygulama yazılımlarının geçişini yönetir. Müşteriler özel yönetim veya dönüştürme sunucularına duyulan ihtiyacı ortadan kaldırırken, mevcut altyapıyı, veritabanlarını veya uygulama yazılımlarını yeniden tasarlamadan ya da yeniden dağıtmadan yıkım onarımı ortamlarını dağıtabilir.

• OCI Full Stack Disaster Recovery hakkında daha fazla bilgi edinin
• OCI için yıkım onarımı hakkında daha fazla bilgi edinin