CADmaster

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

Хочу сразу предупредить, что эта статья не претендует на всеобъемлющий анализ требований, предъявляемых к аппаратному обеспечению систем управления базами данных (СУБД). Предложенные здесь конфигурации оборудования могут плохо подходить к программным решениям, существенно отличающимся по архитектуре и назначению от TDMS. Но для систем, близких по назначению, эти решения могут использоваться достаточно уверенно. Так, для любых клиент-серверных систем класса ECM, DDM, PDM и им подобных предложенный ниже конфигуратор можно рекомендовать для получения дополнительной метрики при выборе сервера.

Критерии оценки

Какие параметры следует учитывать для расчета конфигурации сервера?

Количество новых информационных объектов, которые будут ежедневно попадать в систему.

Следует понимать, что каждый информационный объект, будь то документ, задание смежному подразделению или почтовое сообщение с вложением, не является одной-единственной строчкой в базе данных. Информационный объект состоит из записей в нескольких связанных таблицах и, например, для документа будет содержать как минимум запись о его сущности и атрибутах, тело документа (файл), права доступа к документу, таблицы связей документа, его версии и другую информацию. Кроме данных, создаваемых приложением, СУБД содержит различную служебную информацию, такую как индексы и лог транзакций, а также резервирует свободное место для будущего роста файлов базы данных. Как правило, измерить объем этой информации можно только опытным путем. Для наиболее типичных приложений, работающих под управлением TDMS, на каждый информационный объект приходится около 25 Кбайт данных.

Количество пользователей, одновременно работающих в системе.

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

Интенсивность работы пользователей с системой.

Интенсивность работы зависит не только от того, насколько глубоко система проникла в производственные процессы организации. Она имеет локальные максимумы — например, в утреннее время, а также в конце периодов сдачи отчетности и фактических материалов по проектам (в России это исторически конец квартала и особенно конец года). Рассчитывая конфигурацию сервера, необходимо опираться именно на такие пиковые отрезки времени. То есть следует задать себе вопрос, какими параметрами должен обладать сервер, чтобы выдержать нагрузку от пользователей в 8:30 утра 10 декабря 2015 года. Да, вы обычный человек и понятия не имеете о том, что будет через три года, но в документе с названием «Обоснование инвестиций на приобретение сервера базы данных TDMS» эмпирический расчет показателей пиковой нагрузки на подсистему ввода/вывода будет выглядеть вполне уместным.

Объемы хранения файловых данных.

Постарайтесь оценить порядок объемов файловых хранилищ. Если не слишком промахнетесь, то в дальнейшем этот вопрос не будет вас сильно беспокоить. В данной статье потребности в объеме, необходимом для хранения файлов, оценены в 1 Мбайт на объект системы.

Деньги, на которые мы выбираем

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

• «Давайте купим сервер по минимуму. Если система (TDMS) приживется и потребует со временем больших ресурсов, то мы с учетом уже полученного опыта будем думать о покупке нового сервера. А старый… ну куда-нибудь пристроим».
• «Пока есть деньги, надо их потратить. Если в следующем году порежут бюджет, нормального сервера нам не видать как своих ушей. Поэтому закладываем по максимуму».

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

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

Мой подход можно писать одной фразой: «Вновь приобретаемая система должна обеспечить приемлемый уровень производительности через три года». То есть при достижении вашим сервером этого преклонного возраста вы должны будете решить, что с ним делать дальше: перепрофилировать на менее требовательные задачи или произвести его обновление.

Почему три года? Средний срок жизни стандартов памяти и процессорных разъемов составляет примерно 5−7 лет. Если вам повезло не родиться в понедельник 29 февраля, то, скорее всего, через три года вы сможете найти подходящие процессор и память для обновления своего сервера. Закладываться на больший период рискованно, на меньший — суетно.

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

Платформа

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

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

Серверы бывают напольными (pedestal) и стоечными (rack-mount). Напольные серверы используются в основном или небольшими компаниями, или в качестве серверов для рабочих групп, то есть там, где приобретение 19-дюймового телекоммуникационного шкафа (19-дюймовая стойка, 19-inch rack) для оборудования нецелесообразно. В любых других случаях шкаф обладает несомненными преимуществами, так как кроме сервера в стойку могут устанавливаться коммуникационное оборудование, дисковые массивы, источники бесперебойного питания и другое оборудование.

Стойка имеет три единицы измерения. Ширина стандартна и составляет 19″ (482,6 мм), глубина варьируется от 600 до 900 мм, а высота измеряется в специальных единицах — юнитах (U), равных 1,75″ (44,45 мм). Стандартная высота шкафа — 42U, но бывают и поменьше. Стоечное оборудование также измеряется в юнитах. Поэтому, если в спецификации вашего сервера указано 1U, это означает, что он предназначен для монтажа в стойку и займет в ней по высоте всего один юнит. В большинстве случаев высота сервера определяет количество дисков с быстрой заменой, которые в него можно установить с передней панели. В сервер 1U может поместиться всего четыре диска размера 3,5″ и теоретически до двенадцати 2,5″ (обычно их число меньше и колеблется от четырех до восьми). В сервер 2U с передней панели можно установить уже до двенадцати дисков 3,5″ и до двадцати четырех дисков 2,5″ и т.д. Помимо увеличения количества дисков, в сервере большей высоты резко возрастают возможности установки дополнительных плат в слоты расширения.

В спецификации серверов очень часто используются некоторые стандартные сокращения и патентованные товарные марки производителей, содержащие слова Advanced, Hyper, Rapid, Fast, Mega, Ultra и т.п. Цены в зависимости от наличия или отсутствия этих слов могут различаться в разы. Если вы не чувствуете себя уверенно в таких вопросах, лучше допросите с пристрастием специалиста вашего поставщика (производителя), чем платформа за 50 тысяч рублей отличается от платформы за 150 тысяч. Если его доводы покажутся вам убедительными, постарайтесь ему поверить.

На что стоит обратить внимание?

• Наличие резервного блока питания, лучше с горячей заменой.
• Наличие встроенного аппаратного RAID-контроллера, желательно с поддержкой уровней 50 и 60.
• Наличие сетевых интерфейсов. Чем больше гигабитных портов установлено в сервере, тем лучше. Если вы работаете на большом предприятии, смотрите в сторону 10 Гбит адаптеров.
• Корзины дисков для горячей замены дисков SATA/SAS и шлейфы для подключения должны быть в комплекте.
• После установки дополнительных сетевых и RAID-контроллеров (если потребуется) должен остаться хотя бы один свободный слот расширения PCIe x8(x16).

Помните: всё, чего не окажется в «стандартной» комплектации платформы, вам рано или поздно придется докупать. Имеет смысл поднапрячься и оценить

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

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

Центральный процессор

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

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

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

Скорость обработки отдельного запроса напрямую зависит от производительности ядра. Чем выше частота процессора и современнее его архитектура, тем большее количество операций в секунду он выполняет. Быстрее выполнил один запрос — быстрее освободился для выполнения следующего. Здесь практически линейная зависимость, за которую, правда, приходится очень серьезно доплачивать. Отношение стоимости между младшим и старшим процессорами одного поколения, отличающимися только тактовой частотой и объемом кэшпамяти, может доходить до пяти и более раз. При этом прирост производительности, как правило, не превышает 50%. Именно по этой причине в подавляющем большинстве случаев нет смысла вкладываться в топовые процессоры. Для выбора процессора рекомендую использовать следующую оригинальную «методику»:

• Возьмите прайс-лист с ценами одной линейки процессоров, которая подходит для выбранной вами платформы.
• Возьмите среднее геометрическое от цен на процессоры (функция СРГЕ-ОМ () или GEOMEAN () в Microsoft Excel).
• Выберите процессор, ближайший по цене к среднему геометрическому ².

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

Объем оперативной памяти

Объем оперативной памяти является наиболее критичным параметром при выборе конфигурации сервера базы данных. Такое трепетное отношение к «оперативке» является следствием других отношений:

• время произвольного доступа к оперативной памяти измеряется в наносекундах и относится к времени доступа к дисковым накопителям, измеряемому в миллисекундах, примерно как 1:50 000;
• скорость последовательного чте-ния/записи оперативной памяти превышает скорость чтения/записи дисковых массивов начального и среднего уровня в десятки раз.

Любые данные, которые не поместились в оперативную память, будут извлекаться с дисков намного медленнее. Для любого сервера базы данных лекарством от всех болезней будет не слабительное, а максимально большой объем памяти, который вы и ваше предприятие можете себе позволить. В идеале объем оперативной памяти должен быть таков, чтобы в нее с некоторым запасом поместилась вся база данных без файлов. На сегодняшний день стоимость памяти позволяет это делать: цена так называемой «серверной» памяти (содержащей код коррекции ошибок, ECC) составляет менее 300 рублей за гигабайт. Если вы планируете иметь через пять лет около миллиона информационных объектов, то ваша база данных без файлов предположительно будет «весить» порядка 25 Гбайт. Следовательно, ваш выбор — 32 Гбайт оперативной памяти (см. таблицу 3), на которые вашему предприятию сегодня придется потратить около 10 тысяч рублей. Еще пару лет назад о таких цифрах мы могли только мечтать.

Если вы обратили внимание, я рассчитывал объем памяти исходя не из трех, а из пяти лет. По истечении трехлетнего срока будет достаточно оценить, хватает ли вашему серверу памяти, и определить степень ее доступности на рынке. Некоторый перезаклад по памяти связан с тем, что при обновлении памяти для обеспечения стабильной работы сервера вам, возможно, потребуется полностью вынуть старую память и поставить новую. Бояться этого не надо, так как через пять лет за те же деньги вы, скорее всего, сможете приобрести не 32, а 128 Гбайт. Лишь бы ваш сервер позволял использовать подобный объем.

Дисковая подсистема

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

Исключение могут составлять только системы с достаточным количеством оперативной памяти, рассчитанные на небольшое количество пользователей, для которых будет предпочтительнее использовать единый RAID 10, чем два отдельных зеркала для базы данных и файлового хранилища. При увеличении количества пользователей желательно переходить к раздельному хранению и использованию быстрых дисков, а затем и вовсе к использованию новейших дисков со скоростью обращения 15  000 об/мин.

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

Сетевые интерфейсы

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

Например, скорость чтения с одного диска 15К достигает 200 Мбайт/с, что уже превышает возможности одного порта в 1 Гбит/с. Что же говорить о RAID 10 или 50, которые одновременно считывают данные с двух и более дисков. Но даже если вы установите в свой сервер несколько гигабитных или 10-гигабит-ных сетевых портов, вы наверняка упретесь в возможности вашего старого сетевого оборудования.

Если полное переоснащение сети предприятия по каким-либо причинам невозможно, то как минимум один уровень устройств — коммутаторы, соединенные с вашим сервером СУБД, — должны соответствовать серверу по уровню производительности. Иногда стоимость этих устройств сравнима со стоимостью самого сервера. Но в данном случае экономия может превратить ваши усилия по созданию «правильного» сервера в пустую трату времени и денег.

Резервное копирование и бесперебойное питание

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

Обновление

Прежде чем принять решение об обновлении «железа», необходимо твердо знать узкие места вашей конфигурации. Нет смысла увеличивать количество и частоту процессоров, если у вас не хватает оперативной памяти. Нет смысла наращивать скорость чтения дисков, если у вас недостаточно быстрые сетевые интерфейсы. Для анализа загрузки отдельных устройств сервера используют утилиту PerfMon (сокращение от Windows Performance Monitor). В SQL Server Management Studio также есть встроенные функции как для анализа загрузки вычислительных и сетевых ресурсов, так и для анализа хода выполнения запросов, что позволяет разделить проблемы аппаратного и программного обеспечения.

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

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

Скачать статью в формате PDF — 5.37 Мбайт