Устойчивост на приложения: Поддържайте Windows приложенията налични

Въведение

Приложенията за Windows често зависят от много повече от сървъра, който ги хоства. Бази данни, услуги за идентичност, съхранение, шлюзове, мрежи и крайни точки на потребителите могат да повлияят на това дали едно приложение остава използваемо по време на прекъсване. Тази статия обяснява как ИТ екипите могат да оценят тези зависимости, да проектират устойчивост около съществуващите приложения за Windows, да наблюдават правилните слоеве и да тестват дали плановете за възстановяване наистина запазват бизнес функциите, на които разчитат потребителите.

Какво е устойчивост на приложенията?

Устойчивостта на приложението е способността на приложението и инфраструктурата около него да продължат да предоставят жизненоважни функции по време на прекъсване и да се възстановят предсказуемо след неуспех.

Смущението може да бъде малко или голямо, а причините могат да варират от повреда на хардуер или операционна система, сривове на приложения, неуспешни актуализации, прекъсвания на бази данни, мрежови прекъсвания, неуспехи при удостоверяване, изчерпване на ресурси, недостъпни зависимости или инциденти със сигурността.

Устойчивата архитектура признава, че провалите са неизменна част и вместо да се стреми да предотврати всеки инцидент, ИТ организациите се опитват да ограничат въздействието на всеки един и да установят контролирани процедури за възстановяване, за да поддържат или възстановят услугата.

Устойчивост на приложенията е повече от време на работа на сървъра

Честа грешка е да се използва наличността на сървър като прокси за наличността на приложението, което работи на сървъра.

За да бъде бизнес приложението наистина достъпно, редица компоненти трябва да бъдат налични едновременно:

Инфраструктура → Операционна система → Приложение → Зависимости → Път за достъп → Потребителска сесия → Бизнес процес

Проблем с който и да е елемент в тази верига може да доведе до фактическа недостъпност на приложението.

Например, сървърът на приложения може да е в добро състояние, докато базата данни му е недостъпна. Публикуваното приложение може да работи правилно, но повреда на шлюза прави невъзможно за отдалечените служители да получат достъп до него. Потребителите дори могат успешно да стартират приложението, но да бъдат възпрепятствани да завършат транзакция, защото лиценз, файл или бекенд услуга не е налична.

Устойчивостта на приложението следователно трябва да се измерва въз основа на способността на потребителя да извърши необходимата бизнес задача, а не дали сървърът е в състояние да отговори на проверка за наличност или здравословно състояние.

Защо устойчивостта на приложенията е различна за Windows приложенията?

Съвременните практики за устойчивост все повече се фокусират върху облачно-родни приложения, контейнери, микросервизи и автоматизирана оркестрация. Въпреки че тези подходи са ценни, те не винаги са приложими за всяка организация.

Много организации имат наследствени приложения за бизнес на Windows, които са разработени преди облачните архитектури да станат често срещани. ERP софтуер, приложения за счетоводство, приложения за производство, приложения за здравеопазване, инженерни приложения и вътрешно разработени приложения могат да бъдат критични за операциите на организацията.

Реархитектирането на тези приложения като микросервизи може да бъде изключително скъпо, технически предизвикателно или дори напълно неизпълнимо, ако организацията не контролира изходния код.

В такива случаи може да има значителна стойност в това да се направят операциите около приложението по-устойчиви, вместо да се опитваме да направим самото приложение по-устойчиво. Публикуване на приложения може да бъде част от този подход, като се запазят съществуващите Windows приложения на централизирана инфраструктура, докато се променя начинът, по който потребителите имат достъп до тях. Това може да включва промени в инфраструктурата, хостваща приложението, като премахване на ограниченията на инфраструктурата, създаване на излишни хостове на приложения, активиране на алтернативни методи за достъп и прилагане на по-отзивчиви процедури за възстановяване на хоста на приложението.

При кой случай наличността на Windows приложение може да се провали?

Изграждането на устойчивост на приложенията започва с откритие на компонентите, които са необходими за успешно предоставяне на приложение от техните хостове до потребителите. Този процес подчертава потенциални точки на неуспех, които могат да сринат цялото приложение.

Хостове на приложения

Приложение, работещо на един Windows сървър, има ясен единствен точка на провал.

Проблемите с хардуера, актуализациите на Windows, корупцията на операционната система, изчерпването на ресурси или неуспехът на приложението могат да нарушат работата на всеки потребител, зависещ от тази машина. Ако изискванията за наличност налагат, могат да бъдат внедрени множество хостове на приложения, за да се намали зависимостта от която и да е машина и да се осигури капацитет, когато сървърът стане недостъпен.

Бази данни, съхранение и други зависимости

Много Windows приложения разчитат на услуги, външни за хостинга на приложението. Тези услуги могат да включват:

• SQL бази данни
• файлови споделяния
• лицензиращи сървъри
• Active Directory
• Система за домейн имена (DNS)
• сертификати
• APIs
• междинен софтуер
• мрежово хранилище
• печатна инфраструктура

Въвеждането на втори сървър за приложения осигурява минимална устойчивост, ако те споделят обща база данни или зависимост от хранилище, която не е налична. Става очевидно, че картографирането на зависимостите трябва да се разшири извън видимата инфраструктура на приложенията.

Аутентификация и идентичност

Потребителите не могат да получат достъп до здраво приложение, ако необходимата инфраструктура за удостоверяване не е налична.

ИТ екипите трябва да идентифицират услугите за идентичност, от които зависят критичните им приложения, и да се уверят, че имат планове за резервиране в случай, че тези ресурси станат недостъпни. Active Directory, облачни платформи за идентичност, услуги за многофакторна автентикация (MFA) и шлюзове за автентикация могат да бъдат използвани за осигуряване на верига на наличност за приложение.

Мрежови и отдалечени достъпни пътища

За централизирани Windows приложения, свързаността между потребителите и средата на приложението представлява друга възможна област на неуспех.

Нека си представим цялата верига:

Устройство на потребителя → Интернет или LAN → шлюз → хост на приложението → бекенд услуги

Разпад на всяко място в тази верига може да попречи на потребителите да изпълняват задълженията си, дори ако приложението работи нормално. Особено важно за разпределени организации, където приложението може да работи в центъра за данни, но да е недостъпно за потребителите на друго място.

Крайни точки

Устойчивостта на приложението не изисква непременно нормалната работна станция на потребителя да бъде налична.

Предоставянето на упълномощени потребители средства за достъп до централизирано хоствани приложения от алтернативно устройство или чрез браузър може да осигури достъп, ако лаптопът стане недостъпен, офисът стане недостъпен или служителите трябва да работят от различно място.

Архитектурата на доставката на приложения може да бъде компонент на по-широка стратегия за бизнес непрекъснатост.

Какъв е процесът на изграждане на устойчивост на приложения за Windows приложения?

Няма една единствена технология, която да направи приложението устойчиво. Вместо това ИТ екипите трябва да намалят броя на неуспехите, които могат да доведат до пълно спиране на функцията, и да се подготвят за контролирани механизми за възстановяване за тези, които остават.

1. Идентифицирайте критични приложения и бизнес процеси

Не всички приложения изискват еднаква степен на защита. Започнете, като определите кои приложения поддържат основни операции, на кои потребители разчитат и каква е тяхната толерантност към времето на неработоспособност.

Две цели за възстановяване превеждат бизнес изискванията в технически спецификации. Насоки на NIST за планиране на извънредни ситуации определя Целевото време за възстановяване (RTO) и Целевата точка за възстановяване (RPO) като ключови параметри за определяне на изискванията за възстановяване:

• Целево време за възстановяване (RTO): продължителност на приемливото време на неработоспособност преди възстановяването на услугата.
• Цел на възстановяване (RPO): интервал от допустима загуба на данни, измерен във време.

Приложение, използвано интензивно за обработка на поръчки, може да има RTO от минути, докато приложение за финансово отчитане, което се изпълнява веднъж седмично, може да си позволи дни на неработоспособност.

RTO и RPO определят типа защита, необходима за приложение: мигновен превключване, бързо възстановяване на услугите или просто документирана процедура за възстановяване.

2. Картографирайте цялата зависимост на приложението

Документирайте всичко, което трябва да бъде там, за да може приложението да върши работата си.

Не спирайте на изпълнимия файл или Windows сървъра. Не забравяйте бази данни, хранилища, удостоверяване, DNS, мрежи, сертификати, лицензионни системи, шлюзове и външни услуги.

За всеки, попитайте:

Какво ще се случи с приложението, ако това изчезне?

Тази задача ще разкрие скрити единични точки на провал и ще установи последователността на възстановяване. Възстановяването на хост на приложение първо не помага много, ако неговата база данни, услуга за идентичност или хранилище все още не са налични.

3. Премахнете критичните единични точки на провал

След като зависимостите бъдат установени, определете кои компоненти да бъдат направени излишни, въз основа на бизнес важността и целите за възстановяване.

В случая с доставката на приложения за Windows, това може да включва разполагане на няколко сървъра за приложения, вместо да се разчита на възможностите на един единствен хост. С слой за балансиране на натоварването, сесиите могат да бъдат разпределени между инстанции на приложения по време на нормални операции. В случай на повреда на хоста, входящите връзки могат да бъдат насочени към здрави инстанции на сървъри за приложения.

Планирането на излишъци трябва да бъде информирано от анализа на зависимостите. Множество сървъри на приложения, които имат достъп до една единствена критична база данни, мрежова шлюз или слой за съхранение, все още представляват единна точка на неуспех.

Дизайнът с висока наличност трябва следователно да разглежда приложенческата услуга като интегрирана единица. За среди на Windows Server, изискващи излишност на ниво инфраструктура, Документация за клъстериране с отказоустойчивост на Microsoft предоставя допълнителни насоки за топологии с висока наличност и възстановяване след бедствия.

4. Разделете приложенията от индивидуалните крайни точки

Инсталирането на критично приложение директно на работната станция на всеки служител може да създаде различен вид проблем с устойчивостта. Ако потребителите загубят достъп до обикновения си компютър, те може също да загубят достъп до приложенията, от които се нуждаят, за да продължат да работят.

Централизиране на приложения на управлявани Windows хостове и представянето на интерфейса на приложението на потребителите елиминира този риск. Данните и състоянието на приложението се съхраняват на управлявания Windows хост и се достъпват от упълномощени крайни точки.

Чрез това правим приложението достъпно за потребителите, дори ако сменят устройства или местоположения. Докато централизирането на приложенията не елиминира инфраструктурните проблеми, то помага да се премести в среда, където може да бъде контролирано от ИТ.

5. Осигурете повече от един практичен метод за достъп

Устойчивост може да бъде постигната и чрез избягване на ненужна зависимост от един единствен тип крайна точка или метод на свързване.

В зависимост от архитектурата на доставката на приложения, потребителите могат да използват различни дистанционен достъп методи, включително RDP-съвместим клиент, специален стартер на приложения, уеб портал или HTML5 браузър сесия.

Алтернативните методи за свързване не трябва да се бъркат с излишността на инфраструктурата. Ако всички разчитат на същия неработещ сървър, приложението все още не е налично.

Те осигуряват устойчивост на достъпа, когато прекъсването засяга нормалното устройство на потребителя, инсталирания клиент или местоположението, а не самата услуга на приложението.

6. Наблюдавайте преди деградацията да стане прекъсване

Устойчивостта на приложението не е само за възстановяване, но ранното откритие може да избегне деградация до прекъсване.

Индикаторите, полезни в средите на Windows приложения, са използването на CPU, натиск върху паметта, капацитет на диска и I/O, използване на мрежата, активни сесии, процес на приложението, време за отговор, неуспешна връзка и наличност на зависими услуги.

Наблюдение на тенденции е от съществено значение, тъй като сървър, който многократно достига своите лимити, все още може да бъде онлайн, докато потребителското изживяване постепенно се влошава.

Праговите известия позволяват на администраторите да разследват предшествениците на инцидент, преди потребителите да загубят достъп.

7. Планирайте за капацитетни пикове и резервиране

Приложение, което оцеляват при повреди на хардуерно ниво, но е напълно неспособно да функционира при увеличени изисквания, не е наистина устойчиво на повреди от какъвто и да е вид.

Планирането на капацитета трябва да взема предвид не само ежедневните модели на използване, но и да отчита пикове поради сезонни изисквания, смяна на смени, растеж или изисквания за хостинг на други приложения.

Особено в среди на хостинг с множество сървъри, загубата на един единствен сървър трябва да бъде отчетена, като се осигури, че другите хостинг възли имат резервен капацитет, за да поемат всякакви процеси, които иначе биха били изпълнени на неуспешния възел.

В противен случай, процедурите за превключване при отказ могат просто да превърнат изолирания инцидент в широк проблем с производителността на системата.

8. Защита на данни и конфигурация

Замяната на Windows сървър е с малка полза, ако ИТ не може да възстанови компонентите, необходими за функционирането на приложението.

Това може да означава, че процедурите за архивиране трябва да включват данни от приложения, бази данни, конфигурационни файлове, сертификати, настройки на приложения, потребителски профили, конфигурация на инфраструктурата, скриптове и информация за лицензиране.

Стратегията ще варира в зависимост от Целта за време за възстановяване (RTO) и Целта за точка на възстановяване (RPO) на приложението.

Над всичко, уверете се, че успешното архивиране не е равно на успешното възстановяване. ИТ екипите трябва да тестват дали е възможно да се възстанови цялата услуга на приложението от защитени данни и конфигурация.

9. Намалете радиуса на въздействие на промените

Не винаги става въпрос за непредвидена катастрофа, която причинява прекъсвания. Те могат да бъдат причинени и от внедрени подобрения. Така че, актуализациите на Windows, ъпдейтите на приложения и драйвери, промените в политиката за сигурност и конфигурацията също могат да имат негативно влияние върху наличността на приложението. Препоръчва се да се избягва извършването на подобни промени на всички производствени хостове едновременно, ако е възможно.

В много-сървърна конфигурация е възможно да се извършват подобренията на етапи, което позволява на администратора да се увери, че всичко работи правилно. Възможността за връщане на направените промени също е съществена.

Следователно, при проектирането на процедури за извънредни ситуации, опцията за възстановяване също трябва да бъде взета под внимание. Процесът трябва да бъде правилно документиран, а персоналът трябва да знае какво да прави, ако промяната не успее, вместо просто да оставя това на тяхната преценка.

10. Дизайн за плавно понижаване на качеството

Устойчивостта не е свързана с поддържането на 100% от нормалните функции в работно състояние по всяко време.

В някои случаи поддържането на операциите за ключови потребители или приложения може да бъде по-важно от това да се запазят всички услуги налични за всички потребители. Приоритетите могат да бъдат установени преди да се случи инцидент от ИТ екипите.

Ако има наличен капацитет, който може да бъде използван, може да има смисъл да се разпредели първо за производство, обслужване на клиенти, финанси или други функции.

Това е грациозно деградиране: запазване на способността да се изпълняват функциите, които генерират най-голяма бизнес стойност, вместо да се допуска провалът на по-малко критични елементи да доведе до срив на цялата система.

Как IT екипите трябва да наблюдават устойчивостта на приложенията?

Наблюдението на отделни сървъри може да бъде полезно, но мониторингът на устойчивостта трябва да отразява общата услуга на приложението, както я възприемат потребителите.

Реалистичният модел се състои от няколко слоя:

Слой	Какво да наблюдаваме	Пример за неуспех
Хост	ЦПУ, RAM, диск, наличност на ОС	Сървърът е претоварен или офлайн
Приложение	Състояние на процеса и услугата	Срива на приложението
Зависимост	База данни, DNS, идентичност, съхранение	Приложението стартира, но не може да работи.
Достъп	Гейтъри, портал, мрежов път	Потребителите не могат да се свържат
Сесия	Активни потребители, неуспехи, латентност	Приложението е онлайн, но не може да се използва.
Бизнес функция	Успешно завършване на работния процес	Потребителят не може да завърши необходимата задача

Слойът на бизнес-функцията е един от най-простите за пренебрегване.

Инфраструктурните табла за управление могат да показват всички сървъри, услуги и мрежови пътища като здрави, докато работният процес на реален потребител е компрометиран. Затова е важно критичните приложения да наблюдават своето здраве от перспективата на операцията, за която са проектирани да поддържат.

Как трябва да се тества устойчивостта на приложението?

Архитектура на устойчивост, която никога не е изпитвала контролирана неуспех, съдържа непроверени предположения.

Използвайте тестване, за да оцените реакцията на системата, когато ключови компоненти станат недостъпни. Тестовете трябва да включват изключване на хост на приложение, спиране на услуга за приложение, симулиране на загуба на мрежов маршрут, проверка на поведението на шлюза или натоварването, възстановяване от резервно копие и достъп до приложението от алтернативна крайна точка.

Процесите за тестване трябва да надхвърлят техническите аспекти на възстановяването. ИТ екипите трябва да прегледат дали известията се изпращат на правилния административен персонал, стъпките за възстановяване се изпълняват в правилната последователност и потребителите могат да извършват реална бизнес задача след възстановяване на услугите.

Оперативните процедури са неразривна част от устойчивата система. Процедури за ескалация на аларми: кой получава алармата? Кой има правото да инициира превключване? Къде са съхранени документите за възстановяване и удостоверенията? Коя зависимост трябва да бъде активирана първа?

Техническата излишност предоставя малко предимство, ако процесите за възстановяване на достъпа не са били тествани.

Какво може да бъде контролният списък за устойчивост на приложението?

Преди да започнат работа по критично приложение за Windows, екипите по информационни технологии трябва да могат да отговорят на следните въпроси:

• Кои бизнес процеси разчитат на приложението?
• Какви са RTO и RPO?
• Кои сървъри, бази данни и външни услуги са необходими?
• Къде са критичните му единични точки на провал?
• Може ли друг хост на приложение да приема потребители, ако един хост се провали?
• Могат ли потребителите да се свържат, ако нормалният им крайна точка или местоположение не е налично?
• Има ли достатъчно резервен капацитет за работа с понижена производителност?
• Активно ли се наблюдават проблеми с инфраструктурата, зависимостите и сесиите?
• Уведомяват ли се администраторите преди важните прагове да станат прекъсвания?
• Защитени ли са данните на приложението и конфигурацията?
• Действително ли е тествано възстановяването?
• Могат ли проблематичните промени да бъдат отменени?
• Документирана ли е последователността на възстановяване?
• Могат ли потребителите да завършат необходимия бизнес процес след възстановяване?

Не всички отговори изискват скъпа инфраструктура с висока наличност. Правилното ниво на защита зависи от разходите и оперативното въздействие на времето на неработоспособност.

Важно е решенията за наличност, излишност и възстановяване да се вземат целенасочено, а не да се приемат за даденост.

Как TSplus може да помогне за поддържането на наличността на Windows приложения?

За организации, които разчитат на съществуващи Windows приложения, можем да помогнем за подобряване на наличността, като централизиране на приложенията на управлявани Windows сървъри и предоставяне на достъп до тях на потребителите чрез RDP-съвместими клиенти, достъп в стил RemoteApp или HTML5 уеб портал. Това намалява зависимостта от индивидуални крайни устройства на потребителите и дава на ИТ екипите повече гъвкавост, когато потребителите трябва да се свържат от друго устройство или местоположение.

TSplus Remote Access може също да поддържа разгръщания с множество сървъри с баланс на натоварването и достъп, базиран на шлюз. Когато се комбинира с устойчиви бази данни, съхранение, услуги за идентичност и мрежови услуги, тази архитектура може да намали зависимостта от един единствен хост на приложение и да помогне за поддържане на достъпа до критични Windows приложения по време на прекъсване на инфраструктурата.

Заключение

Устойчивостта на приложението зависи от разбирането на целия път между инфраструктурата и бизнес употребата. Резервирането, мониторингът, архивирането, планирането на капацитета и процедурите за възстановяване са най-ефективни, когато са проектирани около ясно определени зависимости на приложението и цели за възстановяване.

За съществуващите Windows приложения устойчивостта често идва от укрепването на средата около софтуера, а не от реконструирането на самото приложение. Ключовият тест остава прост: когато настъпи смущение, могат ли потребителите да продължат да работят или може ли ИТ да възстанови необходимата бизнес функция в рамките на уговорения времеви прозорец за възстановяване?