Доступная производственная архитектура программного обеспечения как услуги на базе ASP.NET и SQL Server

Итак, вы задумываетесь о том, как спроектировать физическую архитектуру, обеспечивающую производительность, масштабируемость, безопасность и доступность продукта? Как обеспечить безопасное подключение группы разработчиков к рабочим серверам? Как выбрать правильное оборудование для веб-сервера и сервера базы данных? Здесь даны ответы на эти и многие другие вопросы .

Введение

Имеется популярный продукт ASP.NET+SQL Server, растущий со скоростью тысяча пользователей в день, и достигнут предел возможностей вашего собственного хостинга. Теперь, имея достаточно денег в кармане, вы планируете переехать на сторонний хостинг, возможно, на совместное размещение или на управляемый хостинг. Итак, вы задумываетесь о том, как спроектировать физическую архитектуру, обеспечивающую производительность, масштабируемость, безопасность и доступность продукта? Как добиться доступности на уровне четырех девяток (99.99%)? Как обеспечить безопасное подключение группы разработчиков к рабочим серверам? Как выбрать правильное оборудование для веб-сервера и сервера базы данных? Следует ли использовать сеть хранения данных (SAN) или только локальные диски на RAID(массив резервных недорогих дисков)? Как безопасно подключить офисные компьютеры к производственной среде?

Здесь даны ответы на все эти вопросы. Сначала показана схема для Pageflakes, обеспечивающая доступность на уровне четырех девяток. Так как Pageflakes является SaaS(software as service - программное обеспечение как услуга) уровня 3, крайне важно построить высокопроизводительный, высокодоступный продукт, который можно использовать круглосуточно (24/7) и в любой точке мира, причем конечный пользователь получает быстрый доступ к своему контенту, с полной персонализацией и кастомизацией контента, и может делиться им с другими и с миром. Итак, следующая производственная архитектура является очень хорошим кандидатом на SaaS уровня 3:

Для начала  беглый обзор:
•    Уровень веб-сервера содержит три веб-сервера в режиме балансировки нагрузки. Каждый веб-сервер вмещает строго одинаковую копию кода и другие артефакты веб-приложения ASP.NET. IIS 6 сконфигурирован строго одинаково. Веб-приложение использует сессию и аутентификацию форм на базе SQL Server.
•    Веб-серверы обращаются к кластеру SQL Server. Есть два активных/пассивных кластера. Один кластер вмещает главную базу данных, хранящую пользователей, страницы и виджеты, а второй кластер вмещает остальные базы данных, такие как отчеты, журналы, геопозиционирование, кеш, RSS(Rich Site Summary - обогащённая сводка сайта), и т.д. Базы данных разделены, исходя из их нагрузки ввода-вывода, так что каждый кластер имеет примерно одинаковую нагрузку ввода-вывода.
•    Серверы базы данных подключены к EMC SAN, где имеется пара томов SAN. В каждом кластере имеется том SCSI RAID 10 для хранения MDF, том SCSI RAID 1 для хранения LDF и том SATA RAID 1 для хранения журналов.
•    Есть один резервный кластер, хранящий доставленный журнал транзакций SQL Server и зеркальное отображение всех баз данных. Это обеспечивает логическое резервирование баз данных, чтобы при повреждении схемы базы данных при выпусках можно было вернуться к резервной базе данных.
Далее объяснены все до единого уровни и аппаратные компоненты и решения, связанные с их выбором.

Веб-уровень

Общедоступный брандмауэр

Сделать: Использовать соединения брандмауэра, подключенного к интернету (общедоступный маршрутизатор поставщиков услуг хостинга или что-нибудь в этом роде) и подключенного к маршрутизатору или коммутатору, называемому внешним маршрутизатором. Этот брандмауэр называется общедоступным брандмауэром (ОБ)

Почему: Без ОБ серверы беззащитно открыты перед интернетом. Можно возразить, что достаточно брандмауэра Windows, но это не так. Брандмауэр Windows не в состоянии столь же успешно, как аппаратные брандмауэры, справляться с распределенными атаками на отказ в обслуживании, TCP-флудом, неправильно сформированными пакетами. В аппаратном брандмауэре есть специализированный процессор, управляющий всей фильтрацией. Если поступит слишком много неправильно сформированных запросов, процессоры веб-серверов будут перегружены защитой от атаки и не смогут выполнять код ASP.NET.
Сделать: На ОБ должны быть открыты только порты 80 и 443. Если не используется SSL, то должен быть открыт только порт 80. Не оставляйте открытым порт удаленного рабочего стола на общедоступном брандмауэре.

Почему: Нельзя открывать серверы перед интернетом для удаленного рабочего стола. Если кто-то перехватит сеанс удаленного рабочего стола, пока вы управляете сервером из кафе через незащищенный Wi-fi – вы обречены. Доступ к удаленному рабочему столу должен осуществляться только через VPN(virtual private network - виртуальная частная сеть).

Сделать: Никогда не открывать порт FTP.

Почему: FTP незащищен, он передает имя пользователя и пароль открытым текстом. Любой с базовыми знаниями о взломе может перехватить имя пользователя и пароль, когда вы входите на рабочий сервер через FTP. Если это обязательно нужно, используйте FTP, не требующий имени пользователя и пароля и позволяющий только писать файлы в конкретную папку и не дающий ничего читать и видеть список файлов на сервере FTP. Таким образом вы никому не раскроете учетные данные сервера и сможете хотя бы передавать файлы на веб-серверы при необходимости. Также убедитесь, что принудительно задана дисковая квота на томе, куда вы загружаете файлы, и что пропускная способность жестко ограничена. В противном случае некто может использовать всю пропускную способность для загрузки огромных файлов и истощить ваше дисковое пространство.

Сделать: Никогда не открывать порты совместного использования файлов

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

Внешний коммутатор с балансировщиком нагрузки

Сделать: Внешний коммутатор имеет функцию балансировки нагрузки, равномерно распределяющую трафик по веб-серверам. То есть каждый веб-сервер, помещенный за балансировщик нагрузки, получает равную долю суммарного трафика. Каждый веб-сервер имеет сетевую карту, подключенную к этому коммутатору. Это общедоступное соединение. Если трафик не превышает 10 миллионов обращений в день, достаточно коммутатора 100Мбит и сетевой карты с такой же скоростью. Можно выбрать брандмауэр с балансировщиком нагрузки, имеющий достаточно портов для подключения всех веб-серверов.
Почему: Отдельная сетевая карта используется для передачи исключительно трафика веб-сайта по специальному сетевому соединению, так что ему не мешает никакой другой локальный трафик.

Коммутатор производит балансировку нагрузки. Не используйте балансировку сетевой нагрузки Windows. Цель – заставить веб-серверы выполнять только свою работу – исполнять код ASP.NET, обращаться к базе данных, возвращать страницы html и статические файлы, и всё тут. Оставьте все остальное другим компонентам. Аппаратные балансировщики нагрузки очень эффективны и более отказоустойчивы. При выборе программной балансировки нагрузки придется периодически перезагружать серверы для решения загадочных проблем типа «сервер не взаимодействует с другими» или «сервер получает слишком много трафика», и так далее.

Сделать: Оставить балансировщик нагрузки простым, производить только базовое циклическое распределение трафика, без причудливого сходства, без разбора заголовка запроса.

Почему: Сходство и фильтрация URL для обслуживания определенных URL от определенного сервера плохо работали. Тратились несчетные часы на общение по телефону со службой поддержки Cisco для диагностирования странного поведения. Служба поддержки предоставляла нескончаемые исправления, исправлявшие одну ошибку, но привносившие другую. Сходство вело себя странно, убирая сервер из балансировщика нагрузки, по-прежнему доставлявшего ему трафик, и так далее. Применялась фильтрация URL, когда некоторый определенный шаблон URL типа www.pageflakes.com/company обслуживается определенным веб-сервером. Но для этого требовалось, чтобы балансировщик нагрузки открывал каждый запрос, разбирал его, находил URL, сравнивал его с длинным список шаблонов URL и решал, куда отправить трафик. Это было плохое решение. Оно заставляло балансировщики нагрузки задыхаться при большом трафике, переполнять свой буфер внутренних ошибок, часто перезагружаться для устранения неполадок, и так далее. Это дало очень ценный урок – “оставляйте балансировщик нагрузки простым – используйте базовый циклический алгоритм”.

Сделать: У каждого маршрутизатора и брандмауэра должен быть резервный.

Почему: При отказе любого устройства активизируется резервное. Если нет резервного общедоступного брандмауэра, то при отказе брандмауэра веб-сайт выходит из строя, пока не заменят брандмауэр. Аналогично при отказе внешнего маршрутизатора/коммутатора веб-сайт выходит из строя. Поэтому следует иметь резервный брандмауэр и коммутатор/маршрутизатор. Тяжело потратиться на устройство, бездействующее 99% времени, но когда оно спасает положение и предотвращает отключение сайта на час, расходы оправдываются. Более того, иногда придется обновлять прошивку брандмауэра или маршрутизатора, и при этом придется перезагрузить устройство. При перезагрузке устройства трафик не может проходить через него. В таком случае подключается к сети резервное устройство, обновляется и перезагружается основное устройство, затем основное устройство подключается к сети и обновляется и перезагружается резервное устройство.

Сделать: Каждый веб-сервер имеет вторую сетевую карту, подключающую веб-сервер к частной сети, где находятся базы данных. На схеме это внутренний маршрутизатор или внутренний коммутатор.
Почему: Не используйте одну и ту же сетевую карту для подключения к частной и к общедоступной сети. Трафик общедоступной сети не должен перегружать трафик локальной сети. Характер трафика в общедоступной сети и в частной сети абсолютно противоположный – общедоступная сеть передает трафик менее частыми длинными очередями (доставка большого HTML- ответа браузерам), а частная сеть передает трафик высокочастотными короткими очередями (осуществление коротких и частых обращений к базе данных).

Сделать: Приобрести относительно мощные веб-серверы с достаточной емкостью запоминающего устройства. В качестве веб-серверов были выбраны серверы Dell 1950, имеющие 2 четырехъядерных процессоры с оперативной памятью 8 ГБ и 3-мя сетевыми картами. Имеется 4 накопителя SATA 500 ГБ в двух RAID 1.

Почему: Том C: расположен на одном RAID 1, содержащем операционную систему, а том D: расположен на другом RAID 1, содержащем код веб-приложения и огромные журналы IIS. Можно подумать, зачем нужно 500 Гб на раздел операционной системы? Очень большая очередь сообщений Майкрософт находится на диске C:. Зачем так много места на диске D:? При включении длинных кук IIS, из-за того что огромные куки аутентификации форм ASP.NET отправляются в каждом запросе и записываются в журнал, журналы IIS сильно разрастаются. Может генерироваться 3 Гб журналов IIS на каждый сервер для сайта со средним трафиком. Следует оставить достаточно места на веб-сервере для хранения журналов IIS за несколько недель, на тот случай, если внутренние системы переместят эти журналы куда-нибудь в другое место при нарушении передачи отчетов.

Сделать: Установить 64битную версию Windows.

Почему: Без 64битной ОС нельзя полностью использовать 4 ГБ ОЗУ или более. Фактически, в 32битной Windows используется около 3.2 GB даже при наличии 4 Гб ОЗУ. У 32битного процессора есть ряд проблем с адресацией, особенно с контроллерами PCI, использующими часть адресного пространства над 3.2 Гб для сопоставления с устройствами. Итак, для Windows доступно меньше 3.2 Гб ОЗУ. Но 64битная ОС позволяет использовать терабайты ОЗУ. 64битная версия каркаса .NET достаточно устойчива, чтобы выполнять мощные приложения. 64битная Windows может плохо работать на персональных компьютерах, но 64битные серверы сейчас весьма надежные. За два года работы вообще не было сбоев.

Сделать: Внутренняя сеть полностью 1Гбит. Все сетевые кабели гигабитные, маршрутизатор/коммутатор поддерживает гигабит. Сетевые карты на веб-серверах, подключенных к внутреннему коммутатору, тоже гигабитные. Потратьте как можно больше средств на эту конфигурацию, чтобы она была самой быстрой.
Почему: Здесь проходят все соединения от веб-сервера к серверам баз данных. По этим соединениям очень часто передается много данных. Каждая страница веб-сайта может делать от 10 до 100 обращений к базе данных. На каждой странице производятся частые и короткие передачи. Следовательно, все соединения локальной частной сети должны быть очень быстрыми и с малой задержкой.

Маршрутизатор для объемных операций будет рассматрен позже.

Возможность подключения VPN

В правой части схемы показана возможность подключения VPN. Брандмауэр с поддержкой VPN подключает офис и перемещающихся пользователей к внутреннему маршрутизатору. Из внутреннего маршрутизатора пользователи попадают в веб-серверы и в серверы базы данных. Подключение должно быть быстрым, если передается много файлов между офисом и производственной средой. Например, если ежедневно сбрасываются гигабайты журналов IIS из рабочих серверов в офис, то для этого требуется очень хорошее подключение, хотя интернет-соединение в офисе всегда будет узким местом. Если имеется подключение T1 от офиса к производственной среде, то 10битные брандмауэр, коммутатор и кабели нормальны, поскольку T1 равен 1.544Мбит/с.

Почему: Зачем нужна VPN? Потому что крайне важно разрешить подключение к производственной среде только через зашифрованный канал. VPN – единственный способ обеспечить полностью защищенное подключение от компьютера к производственной среде и предотвратить перехват или кражу сессии. К тому же, VPN создает дополнительный уровень защиты на базе имени пользователя и пароля, требуемых для входа в производственную среду. То есть, даже при краже учетных данных сервера, если они хранились в USB-брелоке, никто все же не сможет подключиться к рабочим серверам, если они не подключены к VPN.

Сделать: Поднять VPN типа сеть-сеть от офисной сети к производственной среде. Использовать маршрутизатор с поддержкой VPN типа сеть-сеть.

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

Сделать: Иметь в офисе маршрутизатор, отделяющий рабочие станции разработчиков и айтишников от остальных рабочих станций.

Почему: Если на маршрутизаторе настроена VPN типа сеть-сеть, все, кто подключен к этому маршрутизатору, имеют доступ к производственной среде. Но ноутбуки менеджеров по продажам не должны иметь доступ к производственной среде. Следовательно, надо изолировать доверенные компьютеры типа рабочих станций разработчиков и айтишников и изолировать остальные компьютеры в сети в разных подсетях. Далее доступ к производственной среде дается только доверенной подсети. В хорошем маршрутизаторе можно установить правила, позволяющие только конкретной подсети слать трафик на IP рабочих серверов. Если в офисе есть локальные промежуточные сервера, надо принять такую же меру предосторожности. Их должна видеть лишь доверенная подсеть. Такая дополнительная мера предосторожности предотвращает нежелательное распространение новых вирусов и червей, которые менеджеры по продажам приносят в офис в ноутбуках.

Уровень базы данных

Серверы баз данных находятся за внутренним маршрутизатором/коммутатором. Можно поместить серверы баз данных в очень защищенную сеть путем изоляции веб-серверов в DMZ, что означает демилитаризованная зона. Но в данном случае не используется брандмауэр DMZ, поскольку он становится наибольшим препятствием для всего трафика между веб-серверами и серверами баз данных. Поэтому используются маршрутизаторы, и разрешается только порту 1433 SQL Server проходить через маршрутизатор от веб-сервера к любому серверу баз данных. Можно использовать коммутаторы, если вы не помешаны на безопасности. Следует защищать каждый сервер путем надлежащего внесения исправлений в них и применения передовых практик безопасности, гарантирующих, что сами серверы всегда остаются защищенными. Если кто-то попадет в веб-сервер, взломав его, строки подключения находятся в читаемом файле web.config. Значит, взломщики могут использовать его для подключения к базе данных и достаточно навредить, например, выполнив запрос DELETE * FROM aspnet_users. Блокировка портов, помещение веб-серверов в DMZ мало помогает. Это мнение основано на ограниченном представлении о способностях взломщиков.

Сделать: Серверы баз данных должны быть очень мощными, имеющими как можно более мощные процессоры и очень быстрые контроллеры дисков и много ОЗУ.

Почему: Работа SQL интенсивно потребляет ресурсы диска и процессора. Чем более мощен процессор, тем быстрей выполняются запросы. Диски должны быть очень быстрыми. Однозначно следует использовать SAS с дисками 15K RPM. Наличие большого объема памяти в контроллере диска приносит большую пользу локальным дискам. Также поставьте как можно больше памяти кеша L2, хотя бы 4 Мб.

Сделать: Хранить MDF и LDF на отдельных физических дисках.

Почему: Большинство чтений происходит из MDF, а большинство записей происходит в LDF. Поэтому надо разместить их на отдельных физических дисках, чтобы чтение и запись выполнялись параллельно, не мешая друг другу. Более того, транзакции сначала применяются к LDF, а затем применяются к MDF. Так что в MDF тоже происходит немало записей.

Сделать: Использовать RAID 10 для MDF или для ситуации интенсивного чтения.

Почему: RAID 10 – самая быстрая конфигурация RAID для чтения. Так как данные распределены по множеству дисков, чтения производятся параллельно. В результате, вместо последовательного чтения данных с одного диска, контроллер RAID читает байты одновременно с множества дисков. Это обеспечивает более быстрое чтение.

Сделать: Использовать RAID 1 для LDF или для ситуации интенсивной записи.

Почему: Так как RAID 1 имеет всего два диска, есть меньше дисков для записи данных. В результате скорость записи выше, чем у других конфигураций RAID высшего порядка. Конечно, RAID 0 самый быстрый, но лишен резервирования. Поэтому он не годится для базы данных, где порча данных вызывает серьезные проблемы.

Сделать: Использовать диски SAS для раздела ОС.

Почему: Кажется дорогим, но SQL Server активно использует подкачку, если недостаточно ОЗУ. Так как файлы подкачки хранятся на локальных дисках, они должны быть как можно быстрее. Иначе производительность подкачки страдает от скорости дисков.

Сделать: Всегда выполнять резервное копирование и доставку журналов на разные физические диски, желательно на RAID 1.

Почему: Резервное копирование требует много записи на диск. То же справедливо для журнала транзакций. Чтение всегда происходит из MDF. Поэтому важно, чтобы запись при резервном копировании шла на другой физический диск(и). Иначе при резервном копировании непрерывное чтение вместе с обычным чтением/записью в MDF перегрузит SQL server. Эта проблема возникала при полном резервном копировании, когда в самый последний момент SQL Server блокировал всю базу данных, чтобы записать самые последние транзакции, произошедшие с момента запуска резервного копирования. База данных была заблокирована слишком долго, из-за чего запросы простаивали и веб-сайт генерировал исключения простоя SQL. Единственный способ сократить время блокировки в последний момент – принять меры, чтобы чтение из MDF производилось очень быстро, и чтобы запись при резервном копировании осуществлялась очень быстро. Поэтому MDF был распределен по большему числу дисков с помощью тома RAID 10, и запись была распределена по меньшему числу дисков с помощью тома RAID 1.

Сделать: Использовать кластеризацию Windows для высокой доступности

Почему: Кластеризация Windows – решение с высокой доступностью, формируемое из одного активного сервера и одного пассивного сервера. На обоих серверах установлен SQL Server. Но одновременно только один сервер остается активным и подключенным к совместно используемому запоминающему устройству – SAN. Всегда, когда активный сервер отказывает, администратор кластера автоматически запускает пассивный сервер и подключает к нему тома SAN. При этом длительность простоя минимальна, потому что издержки переключения на другой сервер – только время запуска SQL Server на пассивном сервере и загрузки базы данных из резервной копии. Обычно пассивный сервер с базой данных 80 Гб запускается за 5 минут. Во время восстановления после отказа он откатывает незавершённые транзакции в LDF.
Но кластер Windows требует наличия SAN. Локальные диски не подойдут. Из этого вытекает следующая рекомендация:

Сделать: Использовать сеть хранения данных (SAN)

Почему: Производительность, масштабируемость, надёжность и расширяемость. SAN – оптимальное решение для хранения. SAN – огромный корпус, внутри которого работают сотни дисков. Она имеет много контроллеров диска, много каналов передачи данных, много памяти кеша. Получается идеальная гибкость в конфигурации RAID, позволяющая добавлять сколько угодно дисков в RAID, совместно использовать диски в многочисленных конфигурациях RAID, и т.д. SAN имеет более быстрые контроллеры диска, больше мощности параллельной обработки и больше памяти кеша диска, чем обычные контроллеры, помещаемые в сервер. Пропускная способность диска при использовании SAN выше, чем у локальных дисков. Можно оперативно увеличивать и уменьшать емкость тома, пока приложение работает и использует том. SAN может автоматически отображать диски, и при отказе диска она автоматически поднимает зеркальное отображение диска и перестраивает RAID.

Но у SAN есть ряд серьезных проблем. Обычно не выбирают специализированную SAN, потому что она слишком дорогая. Покупают несколько дисков из существующей SAN у поставщика услуг хостинга. Поставщики услуг хостинга обслуживают много клиентов из одной и той же SAN. Они предоставляют место на дисках, на которых может работать база данных другого клиента. Например, SAN имеет диски SAS 146Гб. Вы запросили хранилище SAS 100 Гб у них. А значит, они отвели вам 100 Гб на диске, а остальные 46 Гб ушли другому клиенту. Следовательно, вы и другой клиент читаете и пишете на один и тот же диск в SAN. Что если другой клиент производит полное резервное копирование в 8 AM? Диск бомбардируется огромными записями, в то время как вы боретесь за каждый бит чтения, который можете получить из этого риска. Что если другой клиент имеет глупого администратора базы данных, не оптимизировавшего базу данных достаточно хорошо и производящего слишком много ввода-вывода на диск? В таком случае вы боретесь за свою долю ввода-вывода на диск. Несмотря на то что контроллеры диска не жалеют сил, чтобы регулировать чтение и запись и дать достаточную долю всем, использующим один и тот же диск, они не всегда справляются. Вы страдаете из-за глупости других. Во избежание данной проблемы покупайте место в SAN в пересчёте на размер физического диска. Если SAN состоит из дисков SAS 146 Гб, покупайте место, кратное 146 Гб. Попросите поставщика услуг хостинга выделить вам целые диски, которые больше никто не использует.

Сделать: Много ОЗУ

Почему: SQL Server делает все возможное, чтобы держать индексы в ОЗУ. Чем больше он может хранить в ОЗУ, тем быстрей выполняются запросы. Обращение к диску и выборка строки более чем в тысячу раз медленнее, чем отыскание этой строки где-то в ОЗУ. Если SQL Server производит слишком много чтений из MDF, добавьте еще ОЗУ. Если Windows осуществляет подкачку, добавьте больше ОЗУ. Продолжайте добавлять ОЗУ, пока чтения с диска не стабилизируются на некотором небольшом значении. Однако это ненаучный подход. Следует измерить счетчик производительности “Доля попаданий в кеш буфера” SQL Server и счетчики “страницы/сек”, чтобы принять взвешенное решение. Но эмпирическое правило – имейте ОЗУ на 2 Гб + 60% размера MDF. Если MDF - 50 Гб, нужно 32 Гб ОЗУ. Причина в том, что не надо держать весь MDF в ОЗУ, потому что все строки не извлекаются время от времени. Как правило, 30% - 40% данных являются журналами, или ревизиями, или данными, к которым обращаются редко. Поэтому надо выяснить, к какой части данных обращаются часто, затем, исходя из этого, вывести объем ОЗУ. По счетчикам производительности лучше всего выяснить, требует ли SQL Server больше ОЗУ.

Сделать: Установить соединение серверов с SAN по волоконно-оптическому каналу с двумя путями

Почему: Волоконно-оптические каналы с двумя путями являются очень быстрым и надежным соединением с SAN. Наличие двух путей означает, что если один отказывает, запросы ввода-вывода идут по другому пути. Это было опробовано вручную. Инженеры технической поддержки просили вручную отключить канал во время работы веб-приложения, и в нем не возникало никаких заметных проблем. Так как SAN походит на сетевые устройства, удаленные от серверов, крайне важно иметь 100% надежное соединение с SAN и иметь план резервного копирования на случай отказа соединения.

Составление отчетов и резервное копирование

Сделать: Иметь отдельный сервер для перемещения журналов 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% доступность за три месяца. Опыт позволяет выбрать оптимальную производственную среду для конкретных нужд приложения.