• Главная
  • Контакты
  • Карта сайта
  • Поиск по сайту

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

Тел.: +7 (495) 666-56-73 (многоканальный)
ICQ: ICQ: 639-649-179 639-649-179, ICQ: 291-109-932 291-109-932

Многоканальный телефон: (495) 666-56-73
E-mail: sales@servergid.ru
ICQ: 639-649-179 Skype: gennady_seleznev
Юридический и фактический адрес: 105082, Москва, ул. Большая Почтовая, дом № 36, строение 5

Схема проезда
Реквизиты

Доставка по Москве в пределах МКАД: 500 руб., при сумме заказа от 50 000 руб. - доставка бесплатная;
Доставка за пределы МКАД: 500 руб.+40 руб./км;
Доставка в любой регион России осуществляется транспортными компаниями (ТК): "Авторейдинг", "ПЭК", "Деловые Линии" , "ЖелдорАльянс", "Желдорэкспедиция" или любой другой по согласованию с клиентом;
Возможен самовывоз.

Новости компании:

13.09.17 

21.08.17 

15.01.16 



Новости отрасли:

04.10.17 

25.05.17 

16.05.16 

Мы в социальных сетях:

Мы в Facebook Мы Вконтакте! Мы в Twitter Мы в Google+


Яндекс.Метрика
Главная  /  Новости  /  Статьи

Статьи

Проектирование серверов баз данных

22.06.15

Проектирование и выбор решения, обеспечивающего работу серверов баз данных


1.    Предисловие


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

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

В статье также приведены примеры решений и их стоимость – исключительно как иллюстрация того, что «правильные» решения с верно заданными входными параметрами не являются какой-то rocket science, не стоят как самолёт или чугунный мост – но вполне приемлемы и применимы в жизни.

2.    Постановка задачи.


Проектирование серверов баз данных

Сервер баз данных

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

Для определения состава того, что должно входить в этот чёрный ящик, необходимо начать с прояснения следующих вопросов:

1.    Сколько всего клиентских рабочих мест – максимум – должно работать с этим решением ?


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

Как именно ?

Если сильно упрощённо проиллюстрировать – то одному пользователю в тот момент времени, когда он производит какие-то действия с базой данных, обслуживающей это решение, требуются вполне конкретные ресурсы: одно процессорное ядро, некий объем ОЗУ, один жесткий диск (его производительность и определенный объем на нём), определенная пропускная способность сетевых интерфейс

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

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

2.    Каков объем данных, с которыми должно работать решение, а также его (объема) прирост за временной период: месяц/квартал год ?


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

3.    Необходимая отказоустойчивость.


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

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

Именно за ними - ответы на определяющие этот параметр вопросы:

- какое время простоя допустимо для этого бизнеса ?

- потеря данных за какой период времени в форс-мажорных обстоятельствах допустима для этого бизнеса ?

«Как можно меньше» - это не ответ, а лишь благое и, в большинстве случаев, не осуществимое за разумную цену пожелание.

На эту тему существуют модные ныне в западном бизнесе ИТ термины:

RTO (Recovery Time Objective) – время восстановления работоспособности сервиса после сбоя. Именно это время будет простаивать бизнес в случае отказа аппаратного обеспечения, обеспечивающего работу базы данных.

RPO (Recovery Point Objective)  - «время в которое было произведено последнее сохранение данных перед отказом», т.е.  время, данные, введенные или рассчитанные в которое будут при отказе аппаратного обеспечения потеряны.

И это уже вполне себе расчётные параметры, прямо влияющие на состав и бюджет решения.

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

Каким же образом рассчитываются RTO и RPO, как их использовать ?

Для определения значения RTO необходимо понимать следующее:

Даже при наивысшем доступном для малого и среднего бизнеса уровне сервиса, когда звонки в сервисный центр  производителя аппаратного обеспечения принимаются 24х7, время реакции инженера СЦ (это именно время реакции – т.е. инженер отзвонится в ИТ-отдел, создавший заявку, в пределах этого времени) составляет 4 часа, время же восстановления работоспособности для одиночного  сервера – сутки.

На следующем уровне сервиса (и он тоже платный) – 9х5 NBD – реакция на заявку и восстановление работоспособности сервера производятся на следующий бизнес-(т.е. рабочий) день.

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

Всё это время, разумеется, неисправный сервер и все сервисы, им обеспечиваемые, будут простаивать.

То есть RTO одиночного сервера, СХД, любого одиночного экземпляра оборудования – от суток (и это – только при наличии приобретенного сервисного пакета) и более.

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

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

Для определения RPO необходимо понимать следующее:

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

- на одиночном сервере с внешним решением резервного копирования RPO равно интервалу времени, в который выполняется перенос резервных копий на внешнее решение: понятно, что «мгновенные снимки» (снэпшоты, snapshots) и оперативные копии данных на хранилище данных внутри этого сервера полностью разделяют с ним риск потери или компрометации целостности данных.

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

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

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

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

3. Исходные данные для грубой оценки.


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

Процессоры:

- на каждые 10 пользователей необходимо 2 физических/4 виртуальных процессорных ядра.

Примечание: некоторое время существовало негативное отношение к технологии HyperThreading, связанное с тем, что на отдельных задачах по производительности виртуальные ядра уступали до 30% в первых версиях этой технологии. Однако – на данный момент производители процессоров эти проблемы уже устранили: фактически, если на рабочем месте не выполняются задачи типа перекодирования видеопотока, или что-то похожее по характеру нагрузки на процессор (непрерывный поток данных с очень большого диапазона адресов в ОЗУ) – потери в производительности стремятся к нулю. Разумеется, вышеописанное исключение как к рабочим местам, работающим с сервером базы данных, так и к собственно аппаратному обеспечению сервера базы данных никак не относится.
ОЗУ:

- разумеется, практически ни при каких обстоятельствах производительность дисковой подсистемы с производительностью ОЗУ не сравняется даже в порядке цифр (задержек на отдачу/запись информации). То есть, чем большая часть БД окажется в ОЗУ – тем быстрее сервер баз данных будет отвечать на запросы пользователей.

То есть в идеале – объем ОЗУ должен превышать объем БД.

Но так ли это на самом деле? Рассмотрим реальную ситуацию.

Чтобы вся база данных оказалась в памяти – ее необходимо туда принудительно «поднять» с дисковой подсистемы специализированными скриптами. Сама по себе она там никогда не окажется, ибо в реальных приложениях никогда не появляется нужда отдавать клиенту базу данных целиком: отдается только то, что запросил клиент (и оно же, соответственно, «поднимается» в кэш БД, если такой запрос конкретно к этим данным был более, чем единичным – и/или в кэше ещё есть/много свободного места).

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

Кроме того, некоторое ПО  серверов баз данных может требовать определенный объем ОЗУ на каждое клиентское подключение.

Более точный ответ, чем вышеприведенный, может дать только разработчик сервера/приложения базы данных, и только применительно к конкретной базе данных в конкретный момент времени.

Опять-таки, расширение ОЗУ – вещь бюджетная лишь до определенных пределов (максимальное количество «средних» (не максимальных) по объему модулей ОЗУ, которое можно установить в материнскую плату данного конкретного сервера), свыше этих пределов расширение ОЗУ может стоить неоправданно дорого.

С другой стороны, ОЗУ на сервере базы данных необходимо и для других целей. Это:

- гипервизор (операционная система виртуализации) и его потребности

- операционная система (в виртуальной машине или на физическом сервере) и ее потребности

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

Приведу некоторые примеры:

Hyper-V нужно минимум 2 ГБ, оптимум 4ГБ

vmWare ESX – 4 ГБ в обоих случаях, на меньшем объеме ОЗУ она просто не заработает

Windows 2012 Server (включая версию R2) – 2 ГБ минимум, 4 ГБ оптимум.

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

Диски.

Наиболее характерной для серверов баз данных является нагрузка типа случайный доступ небольшими блоками (менее 64 КБайт). И вот какие базовые значения для дисковой подсистемы в целях определения необходимого ее объема и количества дисков/SSD можно использовать:

- в синтетических тестах SATA/SAS диски 7200 об/мин обеспечивают примерно 120+ IOps (Input-Output operations per second), 10 тыс. об/мин – 400-450 IOps (и это не относится к SATA дискам 10 тыс. об/мин типа WD Raptor – те по производительности на случайный доступ недалеко ушли от дисков 7200 об/мин), 15 тыс. об/мин – 500+ IOps

- в тех же синтетических тестах «средние» SSD SATA/SAS Enteprise-класса обеспечивают порядка 10 тыс. IOps (т.е. один SATA SSD эквивалентен по производительности примерно сотне SATA или двадцати 15 тыс. об/мин SAS или FC – жестким дискам)

- PCI-E SSD (NVMe) Enterprise-класса в «синтетике» выдают примерно 100 тыс. IOps, т.е. являются эквивалентом по производительности тысячи SATA дисков 7200 об/мин или 200 – SAS/FC 15 тыс. об/мин

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

 Контроллеры
RAID-контроллеры – это уровень абстракции между операционной системой сервера и жесткими дисками, «прячущий» от ОС и реальную раскладку данных по дискам, и их отказы/ сбои.

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

Нагрузка на RAID-контроллеры, которую они могут парировать, зависит от нескольких факторов. Тут необходимо понимать, что “работа” RAID-контроллера состоит из двух частей: это управление чтением/записью блоков данных с/на диски и вычисление контрольных сумм (parity).

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

Программные и частично-программные RAID-контроллеры:

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

Аппаратные RAID-контроллеры:

Имеют в составе универсальный либо специализированный процессор для задачи управления процессами записи и чтения блоков данных, а также – вычислительный процессор или блок для вычисления контрольных сумм с аппаратным ускорением. Уже в нескольких поколениях RAID-контроллеров этот функционал выполняется на одном чипе (либо специализированные RoC – RAID-on-Chip, либо универсальные процессоры, производительности которых с запасом хватает на эти задачи).

Соответственно, аппаратные RAID-контроллеры бывают внутренние (впаянные в материнские платы либо устанавливаемые в слоты PCI-E) и внешние (устанавливаемые в системы хранения данных и подключаемые через адаптер (HBA – Host-Bus Adapter), также впаянный либо устанавливаемый в слоты PCI-E сервера).

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

Внутренние RAID-контроллеры.

Собственно, при рассмотрении подключения именно жестких дисков к ним – нет ничего особенного, все современные RAID-контроллеры способны без проблем «переварить» нагрузку, обрабатываемую даже и несколькими десятками жестких дисков на 15 тыс. об./мин., есть лишь определенные моменты, которые нужно знать:

- уровни RAID: наивысшую производительность на чтение современные RAID-контроллеры показывают на всех уровнях RAID, разница начинается лишь на записи. Наивысшую производительность на запись RAID-контроллеры показывают на уровнях RAID 0,1,10 – т.к. вычислительный блок почти не задействован, вычисления контрольных сумм производятся по минимуму (лишь в части целостности блоков/страйпов данных), данные просто распределяются по дискам и/или дублируются теми же единицами (страйпами). Наихудшую – соответственно, на тех уровнях RAID, где вычислительные возможности контроллера задействуются полностью, это RAID 5,6,50,60 соответственно. Опять-таки, контроллеру необходимо еще и прочитать «соседние» страйпы перед записью – как раз для расчёта контрольных сумм, что тоже не улучшает производительность массива.

Решение вечной проблемы – «производительность (RAID1/10) или объем(RAID5/6)» - тем не менее, существует: это кэширование с помощью SSD (технологии LSI CacheCade, Adaptec MaxIQ, HP SmartCache и т.п.).

Но и оно имеет свои ограничения: необходимо, чтобы объем кэша на SSD гарантированно превышал объем наиболее часто используемых данных, иначе такой кэш из ускорителя станет тормозом (просто добавит операций контроллеру на «протаскивание» потоков данных сквозь этот кэш, не добавив производительности при этом).

Кэширование чтения на SSD не даёт мгновенного прироста производительности: напротив, контроллер сначала на протяжении нескольких часов (12 часов-сутки в зависимости от конкретного контроллера и настроек ПО) строит статистику по наиболее часто читаемым блокам, и раз-два в сутки «поднимает» копии этих данных в кэш.

Кэширование записи на SSD, напротив, даёт мгновенный прирост производительности – но оно же и наиболее серьезно опустошает ресурс перезаписи SSD: то есть, если Вы планируете включение кэширования записи на SSD – необходимо приобретать SSD с большим ресурсом на перезапись (например, Intel S3700 серии, с гарантированной 5-кратной перезаписью своего объема на протяжении 5 лет).

Но что, если мы хотим добиться наибольшей производительности дисковой подсистемы с RAID-контроллером, то есть размещаем наиболее критичные к производительности данные сразу на томе, состоящем из SSD ?

Вот тут и всплывают ограничения уже производительности контроллеров: современные внутренние аппаратные RAID контроллеры способны утилизировать производительность не более, чем 4 SSD одновременно. Ну то есть, поставить-то можно и больше, но вот рост производительности при добавлении SSD в массив свыше 4 штук будет минимальный – или его не будет вовсе.

Разумеется, есть способы несколько улучшить производительность внутренних аппаратных RAID с SSD – например, сменой алгоритмов кэширования (лицензия FastPath у LSI, приобретается для MegaRAID 9200 серии отдельно, в 9300 серии поставляется сразу в составе контроллера) – но радикального (в разы) роста производительности при увеличении количества SSD в массиве они тоже не дают.

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

Тем не менее, для задач БД, если потребное для задачи количество дисков выходит за 12-24 штуки, уже имеет смысл выносить диски во внешние СХД – и не только ради повышения производительности, но и в целях улучшения отказоустойчивости решения в целом.

Внешние RAID-контроллеры:

Здесь будут рассмотрены только СХД начального уровня, т.к. задача «объять необъятное» для этой статьи не стоит.

Существуют решения без внешних контроллеров – это JBOD (Just a Bunch Of Disks, дисковые корзины), подключаемые к контроллерам, устанавливаемым в серверы – и их, понятно, касаются все ограничения, описанные для внутренних RAID-контроллеров.

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

Итак, ниже – «аксиомы» и базовые значения для расчёта параметров решения, содержащего внешнюю СХД.

- производительность: никакие СХД начального уровня не проектируются по производительности в расчёте на максимальное количество дисков, которое можно в них установить. Обычно исходят не более, чем из трети-половины от максимального количества дисков. То есть, если Вашу СХД предполагается набить более, чем наполовину ее максимальной емкости с самого начала – крайне рекомендуется выбирать уже из решений выше уровнем, иначе есть риск не получить нужной производительности впоследствии, при добавлении отдельных дисков и корзин с ними.

- количество дисков

На самом деле, если объем наиболее часто используемых данных не слишком велик, а требуемую производительность нужно парировать более, чем одной корзиной – до 24 дисков 15 тыс. об/мин – имеет смысл смотреть на SSD.

- типы нагрузок

Если СХД выделена под конкретные задачи, то настроить производительность можно и вручную, «раскладывая» дисковые тома на массивы, в которых используются диски нужных объема и производительности.

Если же на СХД предполагается сосуществование данных многих задач и сервисов, причем – с расширением списка в будущем и непонятным на момент проектирования характером этих нагрузок – имеет смысл использовать SSD-кэширование и/или т.н. tiering (автоматическое либо ручное распределение данных «по уровням»). Здесь под «уровнем» подразумевается следующее:

диски собираются не в «обычный» массив из однотипных дисков, но в «пул» из разнотипных дисков разного назначения: SSD, SAS/FC диски 15 или 10 тыс. об/мин, SAS/SATA диски 7.2 тыс. об/мин. При этом контроллеры СХД выполняют сбор статистики по обращениям к конкретным блокам данных, и раз в определенный период (12 часов-сутки, зависит от настроек конкретной СХД) перемещают данные, к которым обращаются наиболее часто, на наиболее высокий по производительности «уровень» дисков (например, на SSD), а те, к которым обращаются редко – на наиболее низкий, но объемный «уровень» (например, на SATA-диски). Таким образом ,в автоматическом режиме создается наиболее эффективное распределение данных по разным типам дисков – но, разумеется, для отдельных задач в конкретные моменты времени оно может оказаться как максимально эффективным, так и неудачным.

Ни в коем случае нельзя путать tiering с кэшированием: в кэш чтения поступают только копии данных, хранящихся на дисках, по «уровням» же перемещаются сами данные (включая блоки контрольных сумм).

- возможность балансировки нагрузки по интерфейсам

Практически все современные СХД имеют возможности балансировки нагрузки по разным интерфейсам контроллеров, в них установленных. Причём эти возможности реализуются как со стороны серверов (драйвера MPIO – multi-path I/O), так и внутри самих СХД (ALUA – Asymmetric Logical Unit Access и т.п.).

Тем не менее, на момент написания статьи автор не видел нормально работающих, широко используемых MPIO-драйверов для интерфейса SAS.

Таким образом, рекомендую: если Вы рассчитываете подключать сервер к более, чем одной одноконтроллерной СХД – используйте интерфейсы FC, Infiniband (SRP+iSER), iSCSI.

Внешние интерфейсы (сеть передачи данных)

Нет смысла сверхбыстро делать выборки из базы данных, если сервер не способен отдать эти данные столь же быстро на рабочее место клиента, верно ?

Таким образом – необходимо обеспечить для отдачи данных «наружу» интерфейсы в нужном количестве и с нужной производительностью.

Разумеется, было бы странным на момент написания статьи строить всю внутреннюю сеть на 10 ГБ Ethernet или чём-то подобном – но на рынке вполне доступны коммутаторы с 2-4 слотами под модули 10Gb Ethernet или аплинками (uplinks, порты для подключения коммутаторов к внутренней высокоскоростной сети ЦОД) на тот же стандарт. Таким образом, при сколько-то серьезных размерах базы данных и количестве пользователей, с ней работающих – вполне себе имеет смысл подключать сервер базы данных к сети предприятия именно по высокоскоростному каналу.

По опыту, если с сетями до 50 пользователей вполне достаточно 1 Гбит Ethernet до сервера, то с 100+ пользователей уже нужно хотя бы вышеописанное подобие высокоскоростной внутренней сети.

Второй момент – внутренняя сеть для репликации данных, синхронной либо асинхронной: понятно, что чем быстрее завершится цикл асинхронной репликации – тем меньше данных будет потеряно; чем быстрее получит данные и ответит «ведомый» сервер при синхронной репликации – тем меньше будет задержка при внесении данных в базу.

Необходимо помнить, что необязательно сразу паниковать о космических ценах на активное оборудование высокоскоростных сетей: в простых случаях серверы можно соединить по 10Gb Ethernet или Infiniband 40/56Gbit (FDR) аж напрямую. Для этого нужны всего-навсего по адаптеру в каждый сервер и по 1-2 кабеля (медных) готовых, оконцованных для соответствующих интерфейсов этих адаптеров. Для понимания – соединить 2 сервера по Infiniband напрямую на момент написания статьи стоит примерно 1200 у.е. (2 1-портовых адаптера и один кабель).

Это обеспечивает великолепную производительность и низкую латентность при обоих видах репликаций, причём малой кровью.

Таким образом, теперь у нас есть базовые значения для расчёта решения хотя бы грубо, сверху.

4. Решение – предварительная (грубая) оценка.


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

Примеры:

1.    10 пользователей, 2 ГБайт база данных, 3-4 документа проводят в час. RTO – сутки и более устраивает (можно восстановить базу данных на какой-нибудь ПК, что позволит, пусть и с потерей производительности работать), RPO – часы (перебить до десятка последних документов – несложно).

Решение: одиночный сервер, с одним процессором (2-4 процессорных ядра, со средненькой производительностью), минимальным ОЗУ (4-8 ГБайт), двумя жесткими дисками SATA в программное «зеркало» (RAID 1) средствами операционной системы, средство резервного копирования – внешний жесткий диск USB 3.0, расписание и метод резервного копирования – в конце рабочего дня принудительно отключаются пользователи базы данных, и простейшей командной строкой 1С по расписанию производится экспорт базы 1С на отдельный каталог внешнего жесткого диска.

2.    25 пользователей, 5 ГБайт база данных, десяток-два документов в час суммарно, RTO – сутки устраивают, RPO – часы.

Решение: одиночный сервер, с одним процессором (6-8 процессорных ядер, производительность на уровне процессоров, установленных в ПК), ОЗУ – 8-16  ГБайт, дисковая подсистема – 2 SSD под БД в  программном «зеркале» (RAID1) + 2 жестких диска SATA 7.2K rpm также в «зеркале» (RAID1) для хранения документов – либо RAID10 из 4 жестких дисков SATA (аппаратный с кэшем на борту и его защитой батарейкой либо флэшем), средство резервного копирования – внешний жесткий диск USB 3.0 в ПК, максимально (в рамках офиса и соответствующего требованиям безопасности данных, в т.ч. в части имеющих право на нём работать сотрудников) удаленного от сервера, резервное копирование средствами встроенного в ОС ПО по расписанию, в конце рабочего дня и дополнительно – еженедельная проверенная на целостность и полная копия БД на тот же ПК. К серверу приобретается сервисный пакет 9x5 NBD (т.е. сервис доступен 9 часов 5 рабочих дней в неделю, восстановление работоспособности на следующий рабочий день).

3.    100 пользователей (офис плюс удаленные офисы/точки продаж локально и по сети, с использованием тонких клиентов или ПО с web-клиентом), база данных MS SQL (1С) объемом 50 ГБайт, рост в год примерно до 15 ГБайт, RTO – минуты (нужно обеспечить бесперебойную работу на протяжении рабочего дня, но без фанатизма), RPO – секунды-единицы минут (потеря введенных документов может повлечь заметные финансовые потери для бизнеса).

Решение:

- кластер серверов баз данных с общим хранилищем данных либо

- кластер серверов с собственными хранилищами данных и асинхронной репликацией между ними

Кластер серверов с общим хранилищем:

- не менее 2 серверов, каждый включает в себя 12-16 процессорных ядер средней производительности, ОЗУ – 64 ГБайт или более, программное «зеркало» из жестких дисков или SSD для загрузки операционной системы и сервисов, Host Bus Adapter (контроллер для подключения к СХД) с интерфейсом iSCSI (1 или 10 Gb Ethernet)/SAS, имеющий не менее 2 портов (для отказоустойчивого подключения к контроллерам системы хранения данных);

- не менее одной системы хранения данных, содержащей не менее 2 контроллеров с тем же интерфейсом, который установлен в серверах для подключения к ней, не менее 12х 15К об/мин дисков минимальной доступной емкости, либо не менее 4хSSD емкостью не менее 400 ГБайт каждый (на протяжении жизни решения, при обнаруженных темпах роста максимальный объем БД составит от 100 ГБайт, плюс объем под журналы сервера БД, плюс необходимый объем под «мгновенные снимки» (снэпшоты), плюс – наиболее эффективный по ресурсу перезаписи режим использования SSD – не более ¾ полного объема), возможна также установка дополнительно 4-8 SATA-дисков под дисковый массив RAID6 для хранения «внешних» (относительно БД) документов и файлов (экспортированные/отсканированные/полученные по средствам связи документы и пр.)

Кластер серверов с собственными хранилищами данных:

- не менее 2 серверов, каждый включает в себя 12-16 процессорных ядер средней производительности, ОЗУ – 64 ГБайт или более, программное «зеркало» из жестких дисков или SSD для загрузки операционной системы и сервисов, аппаратный RAID-контроллер, не менее 4x SSD емкостью не менее 400 ГБайт каждый (соображения, по которым выбран объем, изложены выше), не менее 4 дисков SATA в RAID6 для хранения «внешних» документов и файлов.

Решение для резервного копирования в обоих случаях:

- файловый сервер с емкостью внутреннего дискового массива не менее 12 ТБ (для поддержания архива БД глубиной не менее года), и возможностью расширения, с интерфейсами не менее, чем 2х 1Gb Ethernet, ПО резервного копирования начального уровня – например, Microsoft System Center / Symantec BackupExec / VEEAM и установленными на серверах кластера соответствующими «агентами» этого ПО.

Резервное копирование выполняется:

 - ежедневно изменения (накопительные, или инкрементальные копии данных)

 - еженедельно – полностью все данные с серверов, включая данные БД, содержимое и настройки операционных систем.

Сервис:

Ко всему перечисленному приобретаются сервисные пакеты 24х7х365, с 4-часовой реакцией и гарантированным восстановлением работоспособности на следующий рабочий день.

Дополнительные средства отказоустойчивости:

Для обеспечения хотя бы минимально необходимой для бизнеса доступности сервиса в условиях форс-мажора приобретается дополнительный сервер, со следующими параметрами: не менее 6 процессорных ядер, не менее 64 ГБ ОЗУ, аппаратный RAID с кэшем на SSD емкостью не менее 200 ГБайт, не мене 4 дисков SATA в RAID10.

Восстановление работоспособности сервиса производится восстановлением резервной копии данных на этот сервер (либо виртуальную машину на этом сервере) с сервера резервного копирования. Сервер работает весь период, пока не будет восстановлена в полной мере работоспособность «основного» кластера.

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

Комплексные решения же на 200 и более пользователей, как правило, являются относительно уникальными (т.е. собранными из «стандартных блоков» – но с учётом особенностей конкретного предприятия и его бизнеса) и требуют более тщательного подхода в получении и анализе данных по необходимой производительности аппаратного обеспечения.




Разделы / Сервера



Полезная информация? Поделись с друзьями!


Наши партнеры

 РЕШЕНИЯ:   ПРОДУКЦИЯ:  УСЛУГИ:  О КОМПАНИИ:
Виртуализация серверов | Малый бизнес (5-25 ПК) | Средний бизнес (25-75 ПК) | Почтовая служба | Резервное копирование | Системы хранения данных (СХД) | Сети хранения данных | Терминальные решения | IP-телефония | Blade-сервера | Вычислительные решения Tesla | Сопроцессоры Intel Xeon Phi | Организация доступа в интернет | Графические станции на технологии Quadro GPU | Кластер серверов | Серверы для FreeNAS, NAS4Free и д.р. | Гиперконвергентная инфраструктураСерверы для 1С | Серверы для офиса | Серверы баз данных | Серверы виртуализации | Серверы видеонаблюдения | Терминальные серверы  | Дисковые полки (JBOD) | Серверы IBM | Серверы LenovoСерверы HP (HPE) | Серверы DELLСерверы SupermicroСерверы Huawei | Системы хранения данных (СХД) | Рабочие станции | Персональные компьютерыТелекоммуникационное оборудование | ИБП | Сетевое оборудование | Купить SSD Enterprise | Купить HDD Enterprise Настройка Серверов | Развертывание и настройка служб систем Microsoft | ИТ-консалтинг | ИТ-аутсорсинг (Абонентское обслуживание) | Проектные поставки оборудования | Оптимизация и аудит СУБД MS SQL | Проектирование и монтаж СКС | Модернизация (апгрейд) серверов | Подбор и поставка снятого с производства оборудования и комплектующих | Проектирование и создание локальной вычислительной сети (ЛВС) | Модернизация профессиональных рабочих станций
Реквизиты  |  Наши партнеры  |  Наши клиенты  |  Вакансии  |   Гарантия и поддержка | Интернет магазин



Сервер Гид - Сервера, системы хранения данныхтел. (495) 666-56-73
e-mail:
© Сервер Гид. Все права защищены.
FAQПоиск по сайтуФайловый архивГостевая книгаФотоальбомКарта сайта


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