Соглашение об уровне обслуживания (Service-Level Agreement - SLA) определяет требования к доступности и производительности конкретного устройства или серверной службы. Обычно оно связано с аварийными ситуациями. Например, общее SLA-соглашение может устанавливать, что Exchange Server под названием EX01 в случае аварии должен быть восстановлен и вновь запущен не позднее, чем через четыре часа. SLA-соглашения часто определены специально в контексте процедуры восстановления после аварий; иногда SLA-соглашения являются базой для такой процедуры. Например, если компания не может обходиться без своей базы данных дольше одного часа, процедура восстановления после аварии должна обеспечивать выполнение этого требования.
Прежде чем SLA-соглашение будет разработано, относящийся к IT-персоналу сотрудник, ответственный за устройство, должен четко знать, как восстановить его в случае любого рода аварий. Этот сотрудник также должен ограничить SLA-соглашение только теми типами аварийных ситуаций, которые предусмотрены утвержденной процедурой. Например, представим, что нет плана на случай недоступности сайта. SLA-соглашение может устанавливать, что если устройство отказало, оно может быть восстановлено с использованием запасных частей за два часа или менее. С другой стороны, если что-то случилось с сайтом, нет информации об ожидаемом времени его восстановления, потому что для этого может понадобиться собирать информацию от сторонних поставщиков, покупать оборудование или переставлять его с других машин. Чем более специализированы SLA-соглашения, тем выше вероятность того, что они подойдут ко всем ситуациям.
Определение разумного соглашения об уровне обслуживания
SLA-соглашение не может быть разработано до тех пор, пока ответственный сотрудник не выполнит тестовое резервное копирование с последующим восстановлением и убедится, что процедура восстановления правильна и данные могут быть успешно восстановлены в отведенное для этого время. Если же SLA-соглашение разработано до того, как определена процедура специальная процедура восстановления, сотрудник должен проверить, насколько стандартная процедура восстановления отвечает требованиям SLA-соглашения. Если не отвечает, может понадобиться разработать специальную, иногда весьма дорогостоящую процедуру.
Выбор устройств для резервного копирования
Каждое устройство может иметь специфические требования к резервному копированию. Назначенный ответственный сотрудник отвечает за исследование и изучение этих требований с тем, чтобы гарантировать, что процесс резервного копирования полностью обеспечивает последующее восстановление после аварии. Как это практикуется для сетевых устройств, должна быть скопирована конфигурация устройства; для серверов это локальные и разделенные хранилища данных, файлы операционной системы, конфигурационные файлы. Некоторые резервные копии состоят из документации и ряда установок в текстовых файлах.
Создание загрузочной дискеты Windows Server 2003
В предыдущих версиях Windows, если создавался RAID-массив первого уровня средствами операционной системы вместо аппаратно-управляемого RAID-массива, администратор должен был создавать специфический загрузочный диск. Этот диск указывал на вторичный диск для загрузки, если первичный диск на томе был поврежден. Windows Server 2003 исключает такую необходимость, поскольку в этой операционной системе предусмотрена дополнительная строка в файле boot.ini, которая указывает на второй том, позволяющий серверу нормально загружаться. Единственный момент, который администратор должен иметь в виду, - ему нужно выбрать правиль­ный пункт опций, которые выводятся на экран при загрузке. Зеркальный том в файле boot.ini называется "secondary plex" ("вторичное сплетение"):
[boot loader] timeout=30
default=multi(0)disk(0)rdisk(0)partition(1)WINDOWS [operating systems]
multi(0)disk(0)rdisk(0)partition(1)WINDOWS="C: Microsoft Windows Server _ 2003 Enterprise Server" /fastdetect
multi(0)disk(0)rdisk(1)partition(1)WINDOWS="Boot Mirror C: - secondary plex"
Этот пример взят из файла boot.ini операционной системы Windows Server 2003, использующей программный RAID-массив первого уровня для системных разделов. Вторая подсистема - это только ссылка, но дисковый контроллер и информация о томе указывают на загрузчик для подключения к правильному разделу.
Иногда загрузочная дискета необходима, особенно если загрузочный и системный тома не совпадают и загрузочные файлы недоступны. В этой ситуации дешевле всего использовать дискету. Чтобы создать загрузочную дискету, сначала ее необходимо отформатировать. Затем на локальной серверной консоли скопировать на нее файлы boot.ini, NTLDR и NTDETECT. Если система BIOS не может найти загрузочные файлы на жестком диске, эта дискета позволит загрузить систему и укажет ей местоположение системных файлов.