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

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

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