В рубрике: Ремонт компьютеров.

Восстановление после сбоев


Объявления:

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

 

Восстановление после сбоев

Если к тому же падение производительности интерфейсов клиент/ сервер считается недопустимым, чаша весов может склониться в сторону метода асинхронного тиражирования с иерархией «ведущий — подчиненный». Права на изменение данных — Data Ownership — остаются за главным вычислительным центром, а база данных резервного центра доступна только для чтения. Если выходит из строя канал связи между между вычислительными центрами или резервный центр, система оперативной обработки транзакций (OLTP) в главном вычислительном центре по-прежнему продолжит свою работу. Она будет регистрировать накапливающиеся транзакции в журнале и скопирует их в асинхронном режиме после восстановления резервного центра.

Из-за особенностей асинхронного тиражирования всегда будет оставаться некоторое количество транзакций, уже зафиксированных в главной системе, но еще не отосланных в резервный центр (pending transactions). Если в главном центре случится авария (имеется в виду механическое разрушение всех носителей информации), эти транзакции будут утеряны. После переключения нагрузки на резервный вычислительный центр OLTP-процесс немедленно возобновится, однако приложения будут располагать не тем массивом данных, что был до аварии. Можно ли смириться с таким положением вещей, приходится решать в каждом конкретном случае. Но руководители IТ-служб должны подумать над этой проблемой еще на стадии планирования: после того, как система рухнет, будет слишком поздно.

Более распространенное бедствие — временный выход из строя главной системы. В зависимости от причины возникновения неполадок (конфликт в ядре ОС, «сгоревший» ЦП и т. п.) простой может продолжаться от нескольких минут до дней. Затем работа продолжится с тем же массивом данных, что и до выхода из строя. Если в комплексе реализован режим обратного дублирования данных с резервной на главную систему, то в резервной системе будут собираться все транзакции, выполненные за время простоя главного сервера. После устранения неисправностей они будут скопированы в главный центр.

 

Предложения:

Leave a Reply

Rambler's Top100