Доступная производственная архитектура программного обеспечения как услуги на базе ASP.NET и SQL Server - Составление отчетов и резервное копирование
ОГЛАВЛЕНИЕ
Составление отчетов и резервное копирование
Сделать: Иметь отдельный сервер для перемещения журналов IIS с веб-сервера.
Почему: Приходится анализировать журналы IIS для составления отчетов о трафике, если не используется Google Analytics или какое-то другое средство анализа, не зависящее от журналов IIS. Нельзя запускать инструмент составления отчетов для анализа журнала IIS на веб-сервере, потому что он расходует ресурсы процессора и диска. Лучше всего внедрить пакетное задание, копирующее суточный журнал IIS на отдельном сервере составления отчетов, где производится анализ.
Сделать: Иметь большое съемное внешнее запоминающее устройство, такое как внешние диски USB
Почему: Во время разработки часто приходится приносить большой объем данных, например резервную копию базы данных, из производственной среды в местный офис. Иногда приходится переносить большой объем данных из какой-либо промежуточной среды в производственную. Передача большого объема данных по сети длительна и ненадежна. Лучше перевезти внешний диск USB, содержащий данные. Можно взять резервную копию рабочей базы данных, сохранить ее на USB с криптостойким шифрованием и перевезти диск USB в офис.
Сделать: Использовать быстрые диски SCSI RAID 1
Почему: Составление отчетов и резервное копирование требует большого ввода-вывода с диска. Перенос данных с веб-сервера или сервера баз данных должен выполняться как можно быстрее. Он не должен замедляться из-за плохого диска на сервере составления отчетов/резервного копирования. Кроме того, анализ большого объема данных отнимает много времени, особенно анализ журналов IIS или восстановление резервной копии базы данных для анализа. Следовательно, диски на сервере составления отчетов тоже должны быть очень быстрыми. Более того, при потере базы данных из-за катастрофического отказа можно использовать сервер составления отчетов в качестве временного сервера баз данных, пока формируется основной сервер баз данных. Однажды администратор удалил рабочую базу данных с основного сервера баз данных. К счастью, было суточное резервное копирование на сервере составления отчетов. Была восстановлена суточная резервная копия на сервере составления отчетов, его сделали основным сервером баз данных на время подготовки настоящих серверов баз данных с рабочей базой данных.
Отдельная сетевая карта и коммутатор для объемных операций
Сделать: Использовать отдельную сетевую карту на всех серверах, подключенных к отдельной частной сети через отдельный коммутатор для объемных операций
Почему: Когда копируется большой файл, например, копируется журнал IIS с веб-сервера на сервер составления отчетов, операция копирования отнимает значительную пропускную способность сети. Она нагружает не только частную сетевую карту, осуществляющую очень высокочастотную связь с серверами баз данных, но и отправляет большую нагрузку на частный коммутатор, уже занятый трафиком, генерируемый всеми веб-серверами и серверами баз данных вместе взятыми. Вот почему следует производить операцию копирования большого файла, такого как копия журнала IIS или резервная копия базы данных, через отдельную сетевую карту и отдельный коммутатор, подключенный к совершенно отдельной частной локальной сети. Необходимо отобразить сетевые драйверы на каждом сервере на отдельный IP сети, чтобы любые данные, переданные этим драйверам, проходили через специализированную сетевую карту и коммутатор для объемных операций. Следует подключить эту сеть для объемных операций к VPN, чтобы при скачивании/отправке больших файлов из офиса не затрагивался высокоприоритетный трафик между веб-серверами и серверами баз данных.
Заключение
Вышеописанная архитектура весьма дорогая, но гарантирует 99.99% доступность. Разумеется, доступность также зависит от работы специалистов. Если они разрушат веб-сайт или удалят базу данных по ошибке, никакое оборудование не спасет. Но наличие достаточного резервного оборудования гарантирует быстрое восстановление и возврат к работе, прежде чем клиенты заметят выход из строя. Описанная тут архитектура стоит около $30K в месяц в условиях управляемого хостинга. Это дорого. Можно купить все оборудование в кредит, и ежемесячный платеж составит $20K на срок до двух лет. Сами решайте, на какой компромисс готовы пойти между оборудованием и доступностью. Исходя из того, какое приложение у вас работает, можно выбрать инфраструктуру поменьше, тем не менее гарантирующую 99.99% доступность. Однажды при недостатке средств весь сайт работал всего на 4 серверах, но была получена 99.99% доступность за три месяца. Опыт позволяет выбрать оптимальную производственную среду для конкретных нужд приложения.