Uygulama Dayanıklılığı: Windows Uygulamalarını Kullanılabilir Tutun

Giriş

Windows uygulamaları genellikle barındırıldıkları sunucudan çok daha fazlasına bağımlıdır. Veritabanları, kimlik hizmetleri, depolama, geçitler, ağlar ve kullanıcı uç noktaları, bir uygulamanın kesinti sırasında kullanılabilir kalıp kalmayacağını etkileyebilir. Bu makale, BT ekiplerinin bu bağımlılıkları nasıl değerlendirebileceğini, mevcut Windows uygulamaları etrafında dayanıklılık tasarlayabileceğini, doğru katmanları izleyebileceğini ve kurtarma planlarının kullanıcıların güvendiği iş fonksiyonlarını gerçekten koruyup korumadığını test edebileceğini açıklamaktadır.

Uygulama Dayanıklılığı Nedir?

Uygulama dayanıklılığı, bir uygulamanın ve etrafındaki altyapının, bir kesinti sırasında hayati işlevleri sağlamaya devam etme ve bir arıza sonrasında öngörülebilir bir şekilde toparlanma kapasitesidir.

Kesinti küçük veya büyük olabilir ve nedenleri donanım veya işletim sistemi arızası, uygulama çökmesi, başarısız güncellemeler, veritabanı kesintileri, ağ kesintileri, kimlik doğrulama hataları, kaynak tükenmesi, mevcut olmayan bağımlılıklar veya güvenlik olayları gibi çeşitli durumlar olabilir.

Dayanıklı bir mimari, hataların kaçınılmaz olduğunu kabul eder ve her olayı önlemeye çalışmak yerine, BT organizasyonları her birinin etkisini sınırlamayı ve hizmeti sürdürmek veya geri yüklemek için kontrollü kurtarma prosedürleri oluşturmayı hedefler.

Uygulama Dayanıklılığı Sunucu Çalışma Süresinden Daha Fazlasıdır

Bir yaygın hata, bir sunucunun kullanılabilirliğini, sunucuda çalışan uygulamanın kullanılabilirliği için bir vekil olarak kullanmaktır.

Bir iş uygulamasının gerçekten erişilebilir olması için, bir dizi bileşenin aynı anda mevcut olması gerekir:

Altyapı → İşletim sistemi → Uygulama → Bağımlılıklar → Erişim yolu → Kullanıcı oturumu → İş süreci

Bu zincirdeki herhangi bir öğedeki bir sorun, uygulamanın etkili bir şekilde kullanılamaz hale gelmesine neden olabilir.

Örneğin, bir uygulama sunucusu sağlıklı olabilirken veritabanı erişilemez durumda olabilir. Yayınlanmış bir uygulama düzgün çalışıyor olabilir, ancak bir geçit arızası uzaktan çalışanların ona erişimini imkansız hale getirir. Kullanıcılar uygulamayı başarıyla başlatabilir, ancak bir lisans, dosya veya arka uç hizmeti mevcut olmadığından bir işlemi tamamlamaları engellenebilir.

Uygulama dayanıklılığı, bu nedenle, bir kullanıcının gerekli iş görevini yerine getirme yeteneğine göre ölçülmelidir, bir sunucunun bir kullanılabilirlik veya sağlık kontrolüne yanıt verip vermediğine göre değil.

Windows Uygulamaları için Uygulama Dayanıklılığı Neden Farklıdır?

Modern dayanıklılık uygulamaları giderek bulut yerel uygulamalara, konteynerlere, mikro hizmetlere ve otomatik orkestrasyona odaklanmaktadır. Bu yaklaşımlar değerli olsa da, her organizasyona her zaman uygulanabilir değildir.

Birçok kuruluşun, bulut tabanlı mimarilerin yaygın hale gelmesinden önce geliştirilmiş eski Windows iş uygulamaları bulunmaktadır. ERP yazılımları, muhasebe uygulamaları, üretim uygulamaları, sağlık uygulamaları, mühendislik uygulamaları ve dahili olarak geliştirilmiş uygulamalar, bir kuruluşun operasyonları için kritik öneme sahip olabilir.

Bu uygulamaların mikro hizmetler olarak yeniden yapılandırılması, organizasyon kaynak kodunu kontrol etmediği takdirde son derece pahalı, teknik olarak zorlu veya hatta tamamen uygulanamaz olabilir.

Bu tür durumlarda, uygulamanın kendisini daha dayanıklı hale getirmeye çalışmak yerine, uygulama etrafındaki işlemleri daha dayanıklı hale getirmenin önemli bir değeri olabilir. Uygulama yayınlama bu yaklaşımın bir parçası olabilir, mevcut Windows uygulamalarını merkezi bir altyapıda tutarken kullanıcıların onlara erişim şekillerini değiştirmektedir. Bu, uygulamayı barındıran altyapıda değişiklikler yapmayı içerebilir; örneğin, altyapı kısıtlamalarını ortadan kaldırmak, yedek uygulama sunucuları oluşturmak, alternatif erişim yöntemlerini etkinleştirmek ve uygulama sunucusu için daha duyarlı kurtarma prosedürleri uygulamak.

Bir Windows Uygulama Erişilebilirliği Hangi Durumda Başarısız Olabilir?

Uygulama dayanıklılığını oluşturmak, bir uygulamanın barındırıcılarından kullanıcılara başarıyla iletilmesi için gereken bileşenleri keşfetmekle başlar. Bu süreç, tüm bir uygulamayı devre dışı bırakabilecek potansiyel arıza noktalarını vurgular.

Uygulama Sunucuları

Tek bir Windows sunucusunda çalışan bir uygulama, belirgin bir tek hata noktasına sahiptir.

Donanım sorunları, Windows güncellemeleri, işletim sistemi bozulması, kaynak tükenmesi veya uygulama hatası, o makineye bağlı her kullanıcıyı etkileyebilir. Eğer kullanılabilirlik gereksinimleri varsa, herhangi bir makineye olan bağımlılığı azaltmak ve bir sunucu kullanılamaz hale geldiğinde kapasite sağlamak için birden fazla uygulama sunucusu devreye alınabilir.

Veritabanları, Depolama ve Diğer Bağımlılıklar

Birçok Windows uygulaması, uygulama ana bilgisayarına dış hizmetlere bağımlıdır. Bu hizmetler şunları içerebilir:

• SQL veritabanları
• dosya paylaşımları
• lisans sunucuları
• Active Directory
• Alan Adı Sistemi (DNS)
• sertifikalar
• APIs
• ara katman
• ağ depolama
• baskı altyapısı

İkinci bir uygulama sunucusunun tanıtılması, ortak bir veritabanı veya erişilemeyen bir depolama bağımlılığı paylaşıyorlarsa, minimum dayanıklılık sağlar. Bağımlılık haritalamanın görünür uygulama altyapısının ötesine geçmesi gerektiği açıktır.

Kimlik Doğrulama ve Kimlik

Kullanıcılar, gerekli kimlik doğrulama altyapısı mevcut değilse sağlıklı bir uygulamaya erişemez.

IT ekipleri, kritik uygulamalarının bağımlı olduğu kimlik hizmetlerini belirlemeli ve bu kaynaklar erişilemez olduğunda devreye alma planlarının hazır olduğundan emin olmalıdır. Active Directory, bulut kimlik platformları, çok faktörlü kimlik doğrulama (MFA) hizmetleri ve kimlik doğrulama geçitleri, bir uygulama için bir erişilebilirlik zinciri sağlamak üzere güvenilir bir şekilde kullanılabilir.

Ağ ve Uzaktan Erişim Yolları

Kullanıcılar ile uygulama ortamı arasındaki bağlantı, merkezi Windows uygulamaları için başka bir olası arıza alanını temsil eder.

Tam zinciri hayal edelim:

Kullanıcı cihazı → İnternet veya LAN → ağ geçidi → uygulama sunucusu → arka uç hizmetleri

Bu zincirdeki herhangi bir arıza, uygulama sağlıklı çalışsa bile kullanıcıların işlerini yapmasını engelleyebilir. Özellikle uygulamanın veri merkezinde çalışıyor olabileceği ancak başka bir konumdaki kullanıcılara erişilemez olduğu dağıtılmış organizasyonlar için önemlidir.

Uç Noktalar

Uygulama dayanıklılığı, bir kullanıcının normal iş istasyonunun mevcut olmasını gerektirmez.

Yetkili kullanıcılara alternatif bir cihazdan veya bir tarayıcı aracılığıyla merkezi olarak barındırılan uygulamalara erişim sağlama imkanı sunmak, bir dizüstü bilgisayar kullanılamaz hale geldiğinde, bir ofis erişilemez olduğunda veya çalışanların farklı bir yerden çalışması gerektiğinde erişimi garanti edebilir.

Uygulama teslimat mimarisi, daha geniş bir iş sürekliliği stratejisinin bir bileşeni olabilir.

Windows Uygulamaları için Uygulama Dayanıklılığı Oluşturma Süreci Nedir?

Tek bir teknoloji uygulamayı dayanıklı hale getirmez. BT ekipleri bunun yerine, bir tam işlevi devre dışı bırakabilecek arıza sayısını azaltmalı ve kalanlar için kontrollü kurtarma mekanizmaları hazırlamalıdır.

1. Kritik Uygulamaları ve İş Süreçlerini Belirleyin

Tüm uygulamalar aynı koruma derecesini gerektirmez. Öncelikle hangi uygulamaların temel işlemleri desteklediğini, hangi kullanıcıların bunlara güvendiğini ve bu uygulamaların kesinti toleransını belirleyin.

İki kurtarma hedefi, iş gereksinimlerini teknik spesifikasyonlara dönüştürür. NIST'in acil durum planlaması rehberi Kurtarma Süresi Hedefi (RTO) ve Kurtarma Noktası Hedefi (RPO) kurtarma gereksinimlerini belirlemek için anahtar parametreler olarak tanımlar:

• Kurtarma Süresi Hedefi (RTO): hizmetin yeniden sağlanmasından önce kabul edilebilir kesinti süresi.
• Kurtarma Noktası Hedefi (RPO): zamanla ölçülen kabul edilebilir veri kaybı aralığı.

Siparişleri işlemek için yoğun bir şekilde kullanılan bir uygulamanın RTO'su dakikalar olabilirken, haftada bir kez çalışan bir finansal raporlama uygulaması günlerce kesinti yaşayabilir.

RTO ve RPO, bir uygulama için gerekli olan koruma türünü tanımlar: anlık geçiş, hizmetlerin hızlı bir şekilde yeniden kurulması veya yalnızca belgelenmiş bir kurtarma prosedürü.

Tüm Uygulama Bağımlılık Zincirini Haritalayın

Uygulamanın işini yapabilmesi için orada olması gereken her şeyi belgeleyin.

Yürütülebilir dosya veya Windows sunucusuyla durmayın. Veritabanlarını, depolamayı, kimlik doğrulamayı, DNS'i, ağları, sertifikaları, lisanslama sistemlerini, geçitleri ve dış hizmetleri unutmayın.

Her biri için sor:

Uygulama bu giderse ne olur?

Bu egzersiz, gizli tek hata noktalarını ortaya çıkaracak ve kurtarma sırasını belirleyecektir. Bir uygulama sunucusunu önce geri yüklemek, veritabanı, kimlik hizmeti veya depolama henüz mevcut değilse pek yardımcı olmaz.

3. Kritik Tek Başarısızlık Noktalarını Kaldırın

Bağımlılık ağacı kurulduktan sonra, iş önemi ve kurtarma hedeflerine dayalı olarak hangi bileşenlerin gereksiz hale getirileceğini belirleyin.

Windows uygulama teslimatı durumunda, bu, tek bir ana bilgisayarın yeteneklerine güvenmek yerine birkaç uygulama sunucusunun dağıtılmasını içerebilir. Bir yük dengeleme katmanı ile, oturumlar normal işlemler sırasında uygulama örnekleri arasında dağıtılabilir. Bir ana bilgisayar arızası durumunda, gelen bağlantılar sağlıklı uygulama sunucusu örneklerine yönlendirilebilir.

Yedeklilik planlaması, bağımlılık analizinden bilgilendirilmelidir. Ancak, tek bir kritik veritabanına, ağ geçidine veya depolama katmanına erişen birden fazla uygulama sunucusu hala tek bir arıza noktası oluşturmaktadır.

Yüksek erişilebilirlik tasarımı bu nedenle uygulama hizmetini entegre bir varlık olarak dikkate almalıdır. Altyapı düzeyinde yedeklilik gerektiren Windows Server ortamları için, Microsoft'in Failover Clustering belgeleri yüksek kullanılabilirlik ve felaket kurtarma topolojileri hakkında daha fazla rehberlik sağlar.

4. Uygulamaları Bireysel Uç Noktalardan Ayırın

Her çalışanın iş istasyonuna kritik bir uygulamanın doğrudan yüklenmesi, farklı bir dayanıklılık sorunu yaratabilir. Kullanıcılar, normal bilgisayarlarına erişimlerini kaybederlerse, çalışmaya devam etmek için ihtiyaç duydukları uygulamalara da erişimlerini kaybedebilirler.

Yönetilen Windows sunucularında uygulamaların merkezileştirilmesi ve uygulama arayüzünü kullanıcılara sunmak bu riski ortadan kaldırır. Veriler ve uygulama durumu, yönetilen Windows ana bilgisayarında saklanır ve yetkilendirilmiş uç noktalar tarafından erişilir.

Bunu yaparak, uygulamayı kullanıcılar için cihazlarını veya konumlarını değiştirdiklerinde bile erişilebilir hale getiriyoruz. Uygulamaları merkezileştirmek altyapı sorunlarını ortadan kaldırmasa da, bunu BT tarafından kontrol edilebilecek bir ortama taşımaya yardımcı olur.

Birden Fazla Pratik Erişim Yöntemi Sunun

Dayanıklılık, tek bir uç nokta türüne veya bağlantı yöntemine gereksiz bağımlılığı önleyerek de sağlanabilir.

Uygulama teslim mimarisine bağlı olarak, kullanıcılar farklı kullanabilirler. uzak erişim yöntemler, RDP uyumlu bir istemci, özel uygulama başlatıcı, web portalı veya HTML5 tarayıcı oturumu dahil.

Alternatif bağlantı yöntemleri, altyapı yedekliliği ile karıştırılmamalıdır. Hepsi aynı başarısız sunucuya dayanıyorsa, uygulama hala kullanılamaz.

Kullanıcının normal cihazını, kurulu istemcisini veya konumunu etkileyen bir kesinti durumunda uygulama hizmetinin kendisinden ziyade erişim dayanıklılığı sağlarlar.

6. İzleme, Bozulma Kesintiye Dönüşmeden Önce

Uygulama dayanıklılığı sadece kurtarma ile ilgili değildir, aynı zamanda erken tespit, bir kesintiye dönüşümü önleyebilir.

Windows uygulama ortamlarında yararlı olan göstergeler CPU kullanımı, bellek baskısı, disk kapasitesi ve G/Ç, ağ kullanımı, aktif oturumlar, uygulama süreci, yanıt süresi, başarısız bağlantı ve bağımlı hizmetlerin kullanılabilirliğidir.

Trend izleme kritik öneme sahiptir, çünkü sınırlarına sürekli yaklaşan bir sunucu çevrimiçi kalabilirken kullanıcı deneyimi yavaş yavaş kötüleşebilir.

Eşik uyarıları, yöneticilerin kullanıcıların erişimini kaybetmeden önce bir olayın öncülerini araştırmalarını sağlar.

Kapasite Artışları ve Yedekleme için Plan Yapın

Donanım düzeyindeki arızalara dayanabilen ancak artan talepler altında tamamen işlevsiz hale gelen bir uygulama, herhangi bir türdeki arızalara karşı gerçekten dayanıklı değildir.

Kapasite planlaması, yalnızca günlük kullanım kalıplarını değil, aynı zamanda mevsimsel talepler, değişim vardiyaları, büyüme veya diğer uygulamalar için barındırma gereksinimlerinden kaynaklanan zirveleri de dikkate almalıdır.

Özellikle çok sunuculu barındırma ortamlarında, bir sunucunun kaybı, diğer barındırma düğümlerinin başarısız düğümde yürütülecek olan herhangi bir işlemi karşılayacak yedek kapasiteye sahip olduğundan emin olunarak hesaba katılmalıdır.

Aksi takdirde, yedekleme prosedürleri izole bir olayı geniş bir sistem performans sorunu haline getirebilir.

8. Veri ve Yapılandırmayı Koruyun

Bir yedek Windows sunucusu, IT uygulamanın çalışması için gerekli bileşenleri geri yükleyemiyorsa pek bir işe yaramaz.

Bu, yedekleme prosedürlerinin uygulama verilerini, veritabanlarını, yapılandırma dosyalarını, sertifikaları, uygulama ayarlarını, kullanıcı profillerini, altyapı yapılandırmasını, betikleri ve lisans bilgilerini içermesi gerektiği anlamına gelebilir.

Strateji, uygulamanın Kurtarma Süresi Hedefi (RTO) ve Kurtarma Noktası Hedefi (RPO) dikkate alınarak değişecektir.

Her şeyden önce, başarılı bir yedeklemenin başarılı bir kurtarma ile eşit olmadığından emin olun. BT ekipleri, korunan verilerden ve yapılandırmadan tüm uygulama hizmetinin geri yüklenmesinin mümkün olduğunu test etmelidir.

Değişikliklerin Etki Alanını Azaltın

Her zaman kesintilere neden olan öngörülemeyen bir felaket durumu söz konusu değildir. Kesintiler, uygulanan iyileştirmelerden de kaynaklanabilir. Bu nedenle, Windows yamanmaları, uygulama ve sürücü güncellemeleri, güvenlik politikası ve yapılandırma değişiklikleri de uygulamanın kullanılabilirliği üzerinde olumsuz bir etki yaratabilir. Mümkünse, tüm üretim sunucularında aynı anda benzer değişiklikler yapmaktan kaçınılması önerilir.

Çoklu sunucu kurulumunda, iyileştirme değişikliklerini aşamalı olarak gerçekleştirmek mümkündür, böylece yöneticinin her şeyin doğru çalıştığından emin olmasına olanak tanır. Yapılan değişiklikleri geri alma yeteneği de önemlidir.

Bu nedenle, acil durum prosedürleri tasarlanırken, geri alma seçenekleri de dikkate alınmalıdır. Süreç düzgün bir şekilde belgelenmeli ve personel, bir değişiklik başarısız olursa ne yapacaklarını bilmelidir; bunu sadece kendi takdirine bırakmamalıdır.

10. Nazik Bozulma için Tasarım

Dayanıklılık, her zaman normal işlevlerin %100'ünü çalışır durumda tutmakla ilgili değildir.

Bazı durumlarda, anahtar kullanıcılar veya uygulamalar için operasyonları sürdürmek, tüm hizmetleri tüm kullanıcılara sunmaktan daha önemli olabilir. Bir olay meydana gelmeden önce öncelikler BT ekipleri tarafından belirlenebilir.

Eğer kullanılabilir kapasite varsa, öncelikle bunu üretim, müşteri hizmetleri, finans veya diğer fonksiyonlara tahsis etmek mantıklı olabilir.

Bu, zarif bir bozulmadır: en fazla iş değeri üreten işlevleri çalıştırma yeteneğini korumak, daha az kritik unsurların başarısızlığının tüm sistemi çökertmesine izin vermek yerine.

IT Ekipleri Uygulama Dayanıklılığını Nasıl İzlemelidir?

Bireysel sunucuları izlemek faydalı olabilir, ancak dayanıklılık izleme, kullanıcılar tarafından algılanan toplam uygulama hizmetini yansıtmalıdır.

Gerçekçi bir model birkaç katmandan oluşur:

Katman	İzlenecekler	Örnek Hatası
Sunucu	CPU, RAM, disk, işletim sistemi kullanılabilirliği	Sunucu aşırı yüklü veya çevrimdışı
Uygulama	İşlem ve hizmet durumu	Uygulama çökmesi
Bağımlılık	Veritabanı, DNS, kimlik, depolama	Uygulama başlatılıyor ancak çalışamıyor.
Erişim	Ağ geçidi, portal, ağ yolu	Kullanıcılar bağlanamaz.
Oturum	Aktif kullanıcılar, hatalar, gecikme	Uygulama çevrimiçi ancak kullanılamaz.
İşlev	Başarılı iş akışı tamamlandı	Kullanıcı gerekli görevi tamamlayamaz.

İşlevsel katman, gözden kaçırılması en basit olanlardan biridir.

Altyapı panelleri, tüm sunucuları, hizmetleri ve ağ yollarını sağlıklı olarak gösterebilirken, gerçek bir kullanıcının iş akışı tehlikeye girebilir. Bu nedenle, kritik uygulamaların desteklemek için tasarlandıkları operasyon perspektifinden sağlıklarını izlemeleri önemlidir.

Uygulama Dayanıklılığı Nasıl Test Edilmelidir?

Kontrollü bir başarısızlık yaşamamış bir dayanıklılık mimarisi, test edilmemiş varsayımlar içerir.

Sistemin ana bileşenleri kullanılamaz hale geldiğinde yanıtını değerlendirmek için test kullanın. Testler, bir uygulama sunucusunu çevrimdışı hale getirmeyi, bir uygulama hizmetini durdurmayı, bir ağ yolunun kaybını simüle etmeyi, geçit veya yük dengeleme davranışını doğrulamayı, yedekten geri yüklemeyi ve uygulamaya alternatif bir uç noktadan erişmeyi içermelidir.

Test süreçleri, kurtarma ile ilgili teknik yönlerin ötesine geçmelidir. BT ekipleri, uyarıların doğru idari personele gönderilip gönderilmediğini, kurtarma adımlarının doğru sırayla gerçekleştirilip gerçekleştirilmediğini ve hizmetler geri yüklendikten sonra kullanıcıların gerçek bir iş görevini yerine getirip getiremeyeceklerini gözden geçirmelidir.

Operasyonel prosedürler, dayanıklı bir sistemin ayrılmaz bir parçasıdır. Uyarı yükseltme prosedürleri: uyarıyı kim alır? Failover'ı başlatma yetkisine sahip olan kimdir? Kurtarma belgeleri ve kimlik bilgileri nerede saklanır? Hangi bağımlılık önce çevrimiçi olmalıdır?

Teknik yedeklilik, erişimi yeniden kazanma süreçleri test edilmemişse pek fayda sağlamaz.

Uygulama Dayanıklılığı Kontrol Listesi Nedir?

Kritik bir Windows uygulaması dayanıklı olmadan önce, BT ekiplerinin aşağıdaki soruları yanıtlayabilmesi gerekir:

• Hangi iş süreçleri uygulamaya dayanıyor?
• RTO ve RPO nedir?
• Hangi sunucular, veritabanları ve harici hizmetler gerektirir?
• Kritik tek hata noktaları nerelerde?
• Bir ana bilgisayar başarısız olursa başka bir uygulama ana bilgisayarı kullanıcıları kabul edebilir mi?
• Kullanıcılar normal uç noktaları veya konumları kullanılamıyorsa bağlanabilir mi?
• Kötüleşmiş işletim için yeterli yedek kapasite var mı?
• Altyapı, bağımlılık ve oturum sorunları aktif olarak izleniyor mu?
• Yöneticiler, önemli eşiklerin kesintiye uğramadan önce uyarılıyor mu?
• Uygulama verileri ve yapılandırma korunuyor mu?
• Gerçekten geri yükleme test edildi mi?
• Sıkıntılı değişiklikler geri alınabilir mi?
• Kurtarma sırası belgelenmiş mi?
• Kullanıcılar kurtarma sonrasında gerekli iş sürecini tamamlayabilir mi?

Tüm yanıtlar pahalı yüksek erişilebilirlik altyapısı gerektirmez. Doğru koruma seviyesi, kesinti süresinin maliyeti ve operasyonel etkisine bağlıdır.

Önemli olan, kullanılabilirlik, yedeklilik ve kurtarma kararlarının varsayılarak değil, bilinçli bir şekilde alınmasıdır.

TSplus, Windows Uygulamalarını Nasıl Sürekli Elde Tutmaya Yardımcı Olabilir?

Mevcut Windows uygulamalarına bağımlı olan kuruluşlar için, uygulamaları yönetilen Windows sunucularında merkezileştirerek ve bunları RDP uyumlu istemciler, RemoteApp tarzı erişim veya HTML5 web portalı aracılığıyla kullanıcılara sunarak kullanılabilirliği artırmalarına yardımcı olabiliriz. Bu, bireysel kullanıcı uç noktalarına olan bağımlılığı azaltır ve IT ekiplerine kullanıcıların başka bir cihazdan veya konumdan bağlanmaları gerektiğinde daha fazla esneklik sağlar.

TSplus Uzak Erişim çoklu sunucu dağıtımlarını yük dengeleme ve geçit tabanlı erişim ile destekleyebilir. Dayanıklı veritabanları, depolama, kimlik hizmetleri ve ağ ile birleştirildiğinde, bu mimari tek bir uygulama ana bilgisayarına olan bağımlılığı azaltabilir ve altyapı kesintisi sırasında kritik Windows uygulamalarına erişimi sürdürmeye yardımcı olabilir.

Sonuç

Uygulama dayanıklılığı, altyapı ile iş kullanımı arasındaki tam yolu anlamaya bağlıdır. Yedeklilik, izleme, yedekleme, kapasite planlaması ve kurtarma prosedürleri, açıkça tanımlanmış uygulama bağımlılıkları ve kurtarma hedefleri etrafında tasarlandıklarında en etkili şekilde çalışır.

Mevcut Windows uygulamaları için dayanıklılık genellikle yazılımın etrafındaki ortamı güçlendirmekten gelir, uygulamanın kendisini yeniden inşa etmekten değil. Ana test basit kalır: kesinti meydana geldiğinde, kullanıcılar çalışmaya devam edebilir mi, yoksa BT, gerekli iş fonksiyonunu belirlenen kurtarma penceresi içinde geri yükleyebilir mi?