Отдельный сервер баз данных

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

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

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

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

Базы данных

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

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

Количество сегментов

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

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

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

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

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

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

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

Зеркальные копии

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

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

Размеры физических дисков

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

Однако каждый физический диск может содержать ограниченное число разделов, причем оно не будет меняться с увеличением общей емкости диска. Если конфигурацию сервера можно ограничить 10-ю дисковыми разделами, вам будет достатрчно двух дисковых накопителей. Выбор 4,2 гигабайтных дисков может привести к тому, что значительная часть пространства каждого серверного устройства останется свободной. Общий объем неиспользуемого пространства удваивается при создании полного набора зеркальных копий.

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

Оперативная память

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

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

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

Как отмечалось выше, SQL Server System 11 нуждается в большем количестве оперативной памяти, чем предыдущие версии сервера. System 11 использует дополнительную память как для своих внутренних потребностей, так и для размещения многочисленных именованных кэш-буферов, а также буферных областей с большими блоками ввода-вывода. Поэтому, планируя конфигурацию сервера System 11, предусмотрите значительно больше оперативной памяти, чем требовалось бы для SQL Server 4.9.2 или System 10.

Размеры файловых систем

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

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

При обновлении версии любого из связанных с сервером программных продуктов на файловых дисках точно так же придется держать двойной набор всех необходимых файлов. Начиная планировать объема файловой системы, определите размеры фактически доступного файлового пространства на каждом диске. Это следует сделать, т.к. в зависимости от конкретной аппаратно”программной платформы вспомогательные структуры файловой системы, создаваемые при форматировании диска, могут занять до 10% его доступного объема.

Выдача на диск дампов баз данных

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

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

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

Выдача на диск дампов журналов транзакций

Регулярное сохранение дампов журналов транзакций различных баз данных сервера — необходимое условие для его восстановления после сбоев. Дампы журналов транзакций лучше всего сохранять именно на диск. Это повысит частоту их сохранения и значительно сократит период замедления работы сервера при сохранении каждого журнала. Частота создания дампов баз данных и журналов транзакций определяется планом защиты данных сервера от сбоев.

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

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

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

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

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

Настройка сервера

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

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

Обмен данными с другими системами

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

Вне зависимости от того, были ли файлы данных созданы на этом же сервере, или перенесены из других систем, их размещение потребует соответствующего пространства файловой системы. Например, при ежедневном импорте 10 мегабайтного файла данных недельный запас его копий займет 70 Мбайт файлового пространства.

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

Запись на диск логических дампов

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

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

Любые дампы баз данных, создаваемые непосредственно из SQL Server, являются физическими дампами — т.е. простыми копиями всей информации, содержащейся в базе данных или журнале транзакций. Когда (обратите внимание, что мы не употребляем здесь слова “если”) вы будете извлекать объект данных из старого дампа всей базы данных, вам потребуется выполнить ряд сложных операций, сводящихся к загрузке полного дампа на подходящее свободное место основного или любого вспомогательного сервера. Затем можно будет получить требуемый объект.

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

Логический дамп позволяет воссоздать объекты базы данных на том же или любом другом сервере, вне зависимости от версии второго сервера и аппаратной платформы, на которой он работает. Это объясняется тем, что логические дампы определяют структуру базы данных на языке Transact-SQL. Их поддержка требует файлового пространства, размеры которого зависят от выбранного плана их создания. (Они могут создаваться, например, еженедельно либо после каждой существенной модификации базы данных.)

Как отмечалось ранее, SQL Server не поддерживает создание логических дампов баз данных. Для этого нужно программное обеспечение независимых фирм”разработчиков — например, программа SQL BackTrack компании DataTools.

Синхронизация серверов

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

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

Ограничения, накладываемые серверной машиной

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

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

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

Сервер тиражирования

Запланированную установку сервера тиражирования Replication Server на одну из серверных машин вашей системы также следует учесть на этапе определения конфигурации этой машины. Сервер тиражирования создает так называемые стабильные очереди запросов (stable queues), используемые для хранения транзакций, подлежащих передаче из основной базы данных для воспроизведения на всех ее копиях. Подобно серверным устройствам SQL Server, очереди тиражируемых запросов размещаются сервером тиражирования в одном или нескольких физических разделов диска с небуферизованным доступом.

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

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

Ленточные накопители серверной машины

Проблема выбора конфигурации накопителей на магнитной ленте только кажется второстепенной.

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

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

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

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

Вы можете следить за любыми ответами на эту запись через 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