Реальный пример: информационная система в целом

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

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

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

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

Основной OLTP-сервер рассматриваемой системы поддерживает 17 баз данных, размещенных на дисковом пространсте следующим образом. Общий объем логических дисковых устройств сервера составляет 12 Гбайт, из которых 8 распределены базам данных, а 4 — свободны для обеспечения возможности увеличения размеров баз данных в будущем. На первый взгляд 4 Гбайт резервного пространства кажутся весьма значительными.

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

Теперь учтем необходимость зеркального резервирования сегментов этой базы данных (в нашем примере зеркальное резервирование охватывает все серверные устройства). Не забудем и о том, что одна четверть всех дисков серверной машины отведена для нужд операционной системы и поддержки файловых систем. В целом к машине основного OLTP-сервера подключены 16 дисковых накопителей по 2,4 Гбайт каждый, причем каждые 4 диска подсоединены к одному контролеру. Из этих 4-х один используется для размещений файловых систем.

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

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

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

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

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

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

При этом период переключения должен пройти незаметно, а этого непросто добиться на практике.

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

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

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

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

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

Сервер поддержки принятия решений (подготовки отчетов)
Главное требование, предъявляемое к серверу подготовки отчетов (серверу поддержки принятия решений — Decision Support Server, DSS) — это способность вместить в себя полный набор копий баз данных основного OLTP сервера.

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

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

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

Однако следует предусмотреть равный объем файловой системы, необходимой для загрузки дампов баз данных и журналов транзакций OLTP сервера с целью синхронизации баз данных DSS сервера. В нашем примере DSS серверу достаточно 20 Гбайт общего дискового пространства, из которых 8 по”прежнему займет файловые системы, а 12 будет распределено серверным устройствам.

Важно подчеркнуть, что даже на DSSсервере требуется запланировать зеркальную копию серверного устройства master. Конфигурация дисков и контроллеров DSS сервера может не совпадать с OLTP сервером.

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

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

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

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

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

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

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

С учетом всего сказанного, нашему серверу разработки приложений также потребуется 20 Гбайт дискового пространства, из которых 8 пойдет на размещение файловых систем, а 12 — необходимых баз данных. Убедитесь заранее, что один сервер разработки приложений сможет обеспечить создание приложений для всех серверов вашей информационной системы, а не одного лишь основного OLTP-сервера.

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

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

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

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

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

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

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

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

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

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

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

DBCC-сервер
При наличии в информационной системе хотя бы одной крупной базы данных вам неизбежно потребуется отдельный DBCC-сервер. Хотя теоретически перед созданием каждого полного дампа базы данных необходимо выполнить полный набор проверок непротиворечивости ее структуры (database consistency checks, dbcc), с ростом размеров базы данных эти проверки занимают все больше времени.

Очень скоро перевод тестируемой базы данных в однопользовательский режим (необходимый для обеспечения корректности результатов dbcc-проверок) становится невозможным с точки зрения
нормальной деловой активности вашей компании.

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

Поскольку SQL Server обеспечивает сохранение и восстановление только полных дампов баз данных, извлечение нескольких компонентов крупной базы данных из ее полного дампа является длительной и громоздкой процедурой. Ее удобнее всего выполнить именно на DBCG-сервере. К тому же, загрузка старого дампа одновременно позволяет проверить состояние магнитной ленты, на которой записан дамп, и убедиться в его пригодности для использования.

Дисковое пространство DBCC сервера должно быть достаточным для размещения всех баз данных OLTP сервера и любой другой базы данных, размеры которой могут потребовать проведения dbcc-проверок на отдельной машине. В нашем примере DBCC-сервер получает 20 Гбайт дисков, распределенных с соблюдением прежней пропорции между файловыми системами и серверными устройствами (8 Гбайт/12 Гбайт).

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

Производительность DBCC сервера может значительно уступать любой из рассмотренных выше серверных машин, поскольку выполнение dbcc-проверок не создает большой нагрузки на процессор.

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

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

Например, переход с SQL Server 4.9.2 на System 11, в результате которого вы теряете возможность загружать в новый сервер дампы баз данных версии 4.9.2. В результате для извлечения информации из старых дампов баз данных версии 4.9.2 вам придется поддерживать работоспособную копию SQL Server версии 4.9.2. Обновляя сервер, позаботьтесь о возможности использования старых дампов, сохраненных до перехода на новую версию SQL Server.

Объем дисков прежней версии сервера определяется, исходя из необходимости загрузки самого большого имеющегося дампа базы данных, созданного до перехода на SQL Server System 10 или последующую версию сервера. Поскольку в нашем примере наиболее крупная база данных имеет объем в 5 Гбайт, для загрузки ее данных и всех необходимых файлов серверной машине с SQL Server 4.9.2 вполне хватит 10 Гбайт дисков. В принципе, прежняя версия SQL Server вполне может работать и на серверной машине одного из перечисленных выше серверов (например DBCC-сервера).

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

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

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

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

Требуемые размеры стабильных очередей транзакций (stable queues) зависят от множества различных факторов. В нашем примере разумно предположить, что машине сервера тиражирования будет достаточно 10 Гбайт дискового пространства, из которых 4 можно распределить файловым системам, а 6 будут заняты устройствами 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