Новость из категории: Информация

Варианты обработки отказов с помощью «облачных» средств. Часть II

Содержание:
1. Часть I;
2. Часть II (Вы читаете данный раздел);
3. Часть III.
Варианты обработки отказов с помощью «облачных» средств. Часть II

Существуют многочисленные методы зашиты прикладных приложений, которые можно перечислить в таком порядке предпочтений:
1. Репликация на уровне приложений, вроде SQL AlwaysOn. репликации между несколькими основными контроллерами домена, группы доступности Exchange Database Availability Groups и т.д. Имея под рукой эти технологии, вы получите полную видимость состояния репликации, контроль над репликациями, а приложения будут защищены от любых отказов.

2. Репликация внутри гостевой операционной системы или репликация на уровне гипервизора, которая может дополнительно подключиться к службе мгновенных снимков VSS, чтобы предоставить периодические точки восстановления для приложений (экземпляры на определенный момент времени для защищаемого прикладного приложения, которые могут быть восстановлены вместо недавнего состояния прикладного приложения).

Варианты обработки отказов с помощью «облачных» средств. Часть II

3. Репликация на уровне хранилища данных. Процесс схожий с монтажом брендовой итальянской плитки (https://www.tile-ceramica.ru/), только проходит в максимально сжатые сроки.

4. Восстановление из резервной копии.

Кроме того, возможен другой вариант, который часто оставляют без внимания, но его место в этом списке зависит от различных условий. Некоторые прикладные приложения не имеют фиксируемого состояния. Подумайте о ферме из 50 веб-серверов, работающих на IIS. Они просто обслуживают запросы, а актуальные данные сохраняются в базе данных. Я не беспокоюсь о состоянии веб-серверов. Таким образом, вместо резервного копирования у меня есть образ сервера IIS или настройки режима DSC для PowerShell, которые в случае аварии создают новую ферму из 50 серверов по шаблону. Такой подход позволяет избежать любого резервного копирования и производить запуск так же быстро, как и активацию процесса создания новых 50 экземпляров.

Варианты обработки отказов с помощью «облачных» средств. Часть II

Кроме того, затраты очень отличаются, а увеличение затрат зависит от использования «облака», оплачиваемого при его применении в качестве целевой системы. Конечно, репликации уровня приложений — наилучший вариант, но они требуют экземпляра приложения для запуска на целевой системе для получения данных, тогда как некоторые другие технологии репликации, возможно, только реплицируют экземпляр хранилища.

Варианты обработки отказов с помощью «облачных» средств. Часть II

Теперь, при наличии «облака», стали доступны различные типы служб. Существуют виртуальные машины, работающие по принципу «инфраструктура как служба», Infrastructure as a Service; службы, предоставляющие платформы по модели Platform as a Service, однако они требуют, чтобы приложения были написаны для модели PaaS. Последнего, вероятно, нет в большинстве организаций, но ситуация изменится с появлением Azure Stack. Также существует служба программного обеспечения, работающая по модели Software as a Service, такая как Office 365. Сегодня что-то типа Office 365 в случае аварийной ситуации используется редко, однако выполненный ранее переход к Office 365 не оставляет сомнений в эффективности этой службы во время аварийной ситуации. Если Exchange, SharePoint и т.д. перемещаются в «облако», то в случае аварийной ситуации вам не только не придется беспокоиться об этих службах, но они станут жизненно важными службами коммуникации, на которые вы сможете положиться и которые будут использоваться во время процесса восстановления после сбоя.

Рейтинг статьи

Оценка
0/5
голосов: 0
Ваша оценка статье по пятибальной шкале:
 
 
   

Поделиться

Похожие новости

Комментарии

^ Наверх