Реальный пример: отдельный сервер баз данных

Обсудим теперь различные факторы, которые следует принять во внимание при планировании конфигурации дискового пространства основного OLTP-сервера информационной системы. Одним из важнейших этапов этого процесса является продуманная оценка необходимого количества дисков и дисковых контроллеров основного сервера. Это объясняется тем, что поле дисков OLTP-сервера определяет конфигурацию дисков всех остальных серверов системы.

Базы данных
Определяя нужное дисковое пространство OLTP-сервера, начните с оценки размеров каждой базы данных, размещаемой на будущем сервере, или уже имеющейся на существующем сервере. Примите во внимание ожидаемые темпы роста этих баз данных со временем. Информация о расширении баз данных в прошлом должна быть интерпретирована с учетом экспоненциального увеличения размеров большинства баз данных, когда линейная экстраполяция прежних темпов роста может скорее навредить, чем помочь.

Здесь важно определить, в течение какого периода времени (например года) создаваемая конфигурация сервера должна оставаться адекватной увеличивающимся объемам баз данных. В нашем примере общий размер баз данных уже достиг 8 Гбайт, а все дисковое пространство, доступное для размещения баз данных, составляет 12 Гбайт. Формально можно допустить увеличение баз данных на 50%. На самом же деле необходимость тщательно контролируемого размещения сегментов баз данных по серверным устройствам и контроллерам приводит к значительному сокращению реально доступного пространства.

Обратившись к данным о расширении основной базы данных, мы увидим, что за прошлый год она увеличилась с 2,5 Гбайт до настоящих 5 Гбайт. Таким образом, за год ее размеры удвоились. В текущем году темпы расширения компании еще более возросли, что затрудняет оценку размеров баз данных, ожидаемых к концу года.

Количество сегментов
Теперь определим количество сегментов, необходимых основным базам данных OLTP-сервера. В нашем примере таких баз три. Самая большая образована обычными сегментами default, system и logsegment, а также двумя пользовательскими сегментами — сегментом некластеризованных индексов ncindexes и сегментом data. Эти сегменты, предназначены для размещения некоторых наиболее крупных таблиц данных.

Поскольку основная цель создания пользовательских сегментов — максимальное повышение скорости сервера, каждый из сегментов необходимо разместить на отдельном контроллере дисков. Поэтому серверная машина должна иметь минимум четыре контроллера, к каждому из которых в нашей основной серверной машине подключается по четыре дисковых накопителя (как отмечалось выше, всего нам необходимо 16 физических дисков).

Две оставшиеся базы данных имеют по четыре сегмента — default, system, logsegment, а также сегмент ncindexes, содержащий некластеризованные индексы таблиц данных. Сегменты баз данных следует разместить отдельно друг от друга на разных контроллерах.

При этом необходимо сбалансировать нагрузку на каждый контроллер (поскольку мы не можем назначить каждому сегменту каждой базы данных свой индивидуальный контроллер). Распределяя сегменты одной из основных баз данных по контроллерам, не забывайте, что эти же контроллеры будут применяться сегментами других часто используемых баз данных. Таким образом, мы сталкиваемся с двумя противоречащими друг другу требованиями.

Во-первых, каждый сегмент базы данных должен находится на отдельном контроллере.

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

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

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

Отметим, что речь идет именно о зеркальных копиях устройств, поскольку SQL Server не поддерживает зеркальное отображение отдельных сегментов или баз данных. Для полного резервирования сегмента требуется присутствие зеркальных копий у всех серверных устройств, используемых для размещения этого сегмента. В нашем примере реализована простейшая схема полного зеркалирования всех имеющихся серверных устройств. Для этого нужно еще 12 Гбайт дискового пространства, равное общему объему всех серверных устройств.

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

В любом случае, никогда не устанавливайте в сервер менее 128 Мбайт памяти (лучше всего 500 Мбайт). Помните, что память кажется дорогой, пока ее стоимость не сравнивается с убытками от медленной работы сервера и затратами труда на его настройку.

Определив общий объем памяти сервера, установите соотношение между размерами кэш-буферов данных и процедур. Первый из этих буферов служит для хранения страниц данных при их чтении и модификации, а второй содержит хранимые процедуры. Разумеется, увеличение каждого буфера повысит быстродействие сервера, поскольку больший процент требующейся серверу информации окажется уже прочитанным с диска и загруженным в соответствующий кэш-буфер.

Определить оптимальный баланс между размерами кэш-буферов данных и процедур можно только путем наблюдения с помощью программы SQL Monitor за долей успешных поисков в каждом буфере. Одновременно варьируйте параметр конфигурации “procedure cache percent”, применяя процедуру sp_configure. По умолчанию, значение этого параметра составляет 20%.

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

Размеры файловых систем
Необходимые размеры файлового пространства сервера наверняка окажутся больше, чем вы могли предполагать. В дополнение к файловым областям, серверной машине также требуется пространство для нужд операционной системы; для размещения области подкачки страниц виртуальной памяти (требуемые размеры уточните у системного администратора серверной машины); для размещения дистрибутивов SQL Server и файлов, необходимых для обеспечения его нормальной работы; для размещения всех других установленных на серверной машине программных
продуктов.

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

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

Таким образом, одновременная запись на диски дампов всех трех баз данных потребует 8 Гбайт файлового пространства. Оно должно быть специально зарезервировано под эти цели — если указанное пространства окажется хотя бы частично занятым другими файлами, сохранение дампов может закончиться неудачей.

Начиная с SQL Server System 10, сохранение дампов баз данных осуществляется исключительно через сервер архивации Backup Server, способный выдавать дамп на несколько ленточных устройств или в несколько дисковых файлов одновременно. Это значительно сокращает время создания дампа.

В случае, если указанные ленточные или дисковые накопители подключены к разным контроллерам ввода-вывода, дамп создается быстрее во столько раз, сколько устройств работает одновременно. В результате создание дампа базы данных можно ускорить в четыре раза по сравнению с его сохранением на одну ленту или диск. Указанное обстоятельство обязательно учтите при планировании распределения дисков и накопителей на магнитной ленте по имеющимся дисковым контроллерам серверной машины.

Выдача на диск дампов журналов транзакций
В течение всего периода между последовательными сохранениями полных дампов баз данных следует обеспечить регулярное сохранение дампов журналов транзакций важнейших баз данных. Определив время, в течение которого должны храниться все дампы журналов транзакций, попытайтесь установить их оптимальный объем, накапливаемый за каждые сутки работы сервера.

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

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

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

Создание новых и изменение структуры существующих индексов требует порой весьма значительного свободного места на диске. Особенно много дискового пространства нужно для создания кластеризованного индекса таблицы — оно может достигать 150% от полного размера индексируемой таблицы данных.

Поскольку в нашем сервере самая крупная таблица имеет длину в 800 Мбайт, мы должны зарезервировать около 1,2 Гбайт для обеспечения будущей настройки сервера. Важно подчеркнуть, что это пространство должно быть доступно для расширения индексного сегмента базы данных. Поэтому оно должно находиться на серверных устройствах, поддерживающих именно этот сегмент.

Если свободного места для размещения индексного сегмента базы данных нет, вновь создаваемые индексы нельзя будет вынести в отдельный сегмент и поместить на отдельный дисковый контроллер. После создания кластеризованного индекса все дополнительное дисковое пространство вновь оказывается свободным. Однако исключить его из cocтaвa базы данных непросто. Кроме того, это пространство может потребоваться в будущем для создания кластеризованных индексов других таблиц.

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

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

Запись на диск логических дампов
Помимо записи обычных дампов баз данных, во многих случаях ощутимую пользу приносит регулярное сохранение логических дампов баз данных. Эти дампы намного облегчают получение информации о структуре и содержании отдельного объекта базы данных.

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

В нашем примере следует хранить только один последний комплект логических дампов всех баз данных сервера. Установим средний размер логического дампа в 50% объема соответствующей базы данных. Тогда логические дампы займут до 6 Гбайт файлового пространства (половину от 12 Гбайт дисков, распределенных под серверные устройства).

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

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

Определяя конфигурацию DBCC-сервера, мы запланировали для него 20 Гбайт дискового пространства, из которых 12 будет занято серверными устройствами, а 8 — файловыми системами. Такого поля дисков действительно хватит при условии, что дампы баз данных будут загружаться в DBCC-сервер непосредственно с магнитных лент.

Однако автоматизированная синхронизация баз данных DBCC-сервера с основным OLTP-сервером потребует обеспечения копирования дисковых файлов дампов баз данных. Для этого понадобится место на DBCC-сервере.

Наша наиболее крупная база данных имеет размер 5 Гбайт. Для временного размещения ее дампа перед загрузкой в DBCC-сервер на нем должно быть зарезервировано 5 из 8 Гбайт имеющегося файлового пространства. Просчитайте, хватит ли имеющихся файловых систем на размещение дампа крупнейшей базы данных системы и всех остальных файлов, требующихся для эффективной работы DBCC-сервера.

Ограничения, накладываемые серверной машиной
До настоящего момента, рассматривая дисковое пространство серверной машины, мы предполагали, что можем подключить к ней неограниченное количество дисков. Следует точно определить, сколько контроллеров можно подключить к каждому из имеющихся в вашем распоряжении компьютеров.

От этого зависят максимальные размеры доступного дискового пространства. Если на какой-то из серверных машин не удается уложиться в это пространство, следует либо заменить эту машину на более мощную, либо поручить часть ее функций другому серверу. Аналогичные проблемы могут возникнуть из”за физического недостатка свободного места для установки новых дисковых накопителей. Количество дисковых стоек, а также кондиционеров и источников питания также должно устанавливаться заранее.

Сервер тиражирования
В нашем случае сервер тиражирования (Replication Server) работает на отдельной серверной машине. Поэтому его присутствие в системе не влияет на размеры дискового пространства серверной машины основного OLTP-сервера.

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

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

Кроме того, емкость накопителей на магнитной ленте каждой серверной машины следует сопоставить с размерами баз данных этого сервера. Увеличиваясь, размеры баз данных могут превысить емкость ленточных устройств. Конечно, один дамп вполне может занимать несколько магнитных лент, но смена лент требует вмешательства персонала и занимает много времени.

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

Заключение
Итак, наша информационная система основана на OLTP-сервере, базы данных которого занимают 8 Гбайт дискового пространства. Мы включили в состав системы шесть отдельных серверов, работающих на шести серверных машинах, предположив, что сервер предыдущей версии удалось разместить на машине одного из остальных серверов. Для сервера “тиражирования Replication Server нам потребовалась седьмая машина.

Мы это сделали для обеспечения нормальной работы пользователей OLTP-приложений и приложений поддержки принятия решений и разработчиков приложений. Эти серверы позволяют быстро восстанавливать работоспособность системы при сбоях основного сервера, своевременно проверять целостность данных и тестировать новые приложения.

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

Если одна из баз данных увеличивается на 1 Гбайт, для успешного сохранения ее дампа файловое пространство и емкость ленточного накопителя соответствующей серверной машины также придется увеличить на 1 Гбайт (плюс поправка на увеличение размеров дампов журнала транзакций). Потом вам придется увеличить емкость дисков всех машин, куда хотя бы эпизодически загружается дамп этой базы данных. В итоге вы заново пройдете все этапы процесса.

Определив нужное вам количество машин, дисков и другого оборудования, не забудьте, что в одиночку вы физически не справитесь с его установкой, эксплуатацией и обновлением. Даже если сейчас вы выполняете все подобные функции самостоятельно, с ростом активности вашей компании вам придется позаботиться о расширении персонала.

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100