Наш администратор сервера разработал план переноса всего хранилища в центральный дисковый шкаф, чтобы каждый сервер использовал его. У нас есть центральный SQL-сервер, который активно используется (200+ одновременных пользователей), и я обеспокоен тем, что это может серьезно повлиять на производительность.
Насколько безопасно использовать центральный дисковый шкаф для хранения баз данных SQL Server? Повлияет ли это на производительность, или возможно ли быстро настроить SQL Server, в котором дисковый шкаф используется совместно со многими другими серверами?
Производительность - это не просто вопрос: «Эй, у меня есть SQL-сервер с 200 пользователями, какая у меня нагрузка на производительность?». Что вы знаете о текущей производительности сервера, особенно о производительности диска? Вот с чего я бы начал.
Кроме того, утверждение о том, что сервер интенсивно используется из-за того, что у вас работает 200 пользователей, также не лучший подход к анализу производительности. Это не просто количество пользователей, это количество транзакций, характер транзакций и т. Д. У меня есть SQL-сервер, на котором работают 2000 пользователей, но я не считаю его широко используемым, исходя из показателей производительности, которые я отслеживаю. и график.
Производительность базы данных (в частности, SQL Server, как описано ниже) может быть низкой на оборудовании SAN. Как правило, подсистема хранения с прямым подключением на сервере базы данных будет дешевле и быстрее. Один из вариантов состоит в том, что вы можете смонтировать том SAN на сервере и сделать резервную копию базы данных на этом томе. У использования SAN для рабочей нагрузки базы данных есть существенные плюсы и минусы:
Плюс: если вы хотите кластеризованные серверы с возможностью горячего переключения, вам понадобится общий диск. Обычно это реализуется с помощью SAN, хотя существуют и другие архитектуры.
Плюс: если вы хотите использовать блейд-серверы, хранилище SAN - единственный разумный вариант.
Плюсы: SAN централизует дисковое хранилище и управление резервным копированием.
Плюсы: SAN (обычно) не имеют единой точки отказа в оборудовании (одна из ключевых особенностей конструкции волоконно-оптического канала), поэтому они могут быть хорошими для систем, которые имеют требования к высокой доступности.
Против: получение приличной производительности базы данных из SAN, настроенной для выполнения общих задач, может быть проблематичным. Часто поставщики рекомендуют выделить для приложения SAN, что в первую очередь противоречит цели наличия SAN.
Против: оборудование SAN дорогое. Часто SAN будет стоить больше, чем подключенное к нему серверное оборудование, особенно если учесть текущие расходы и резервное копирование.
Против: SAN образуют еще одну контрольную точку, привлекательную для строителей империй. Если вам понадобится еще одна дисковая полка, первоначальные затраты также могут вызвать внутреннее трение, если для этого не выделено специально выделенное финансирование.
Мой инстинкт подсказывает, что вы должны заставить специалистов по инфраструктуре доказать, что система будет адекватно работать в SAN (то есть протестировать ее), и подготовить убедительное экономическое обоснование, прежде чем позволить им перенести на нее сервер.
В частности, не покупайте больше SLA, чем вам действительно нужно. На самом деле реализация высоких уровней надежности очень дорога, и простое подключение вашего сервера к сети SAN само по себе не приведет к этому, так что это ложный аргумент, если он не подкреплен действительными требованиями.
Насколько безопасно использовать центральный дисковый шкаф для хранения баз данных SQL Server?
Если это достаточно хороший центральный блок SAN, тогда да, вы захотите, чтобы он имел двойной контроллер и пути к диску, а также множество хост-портов, но да, это может быть намного безопаснее.
Повлияет ли это на производительность, или возможно ли быстро настроить SQL Server, в котором дисковый шкаф используется совместно со многими другими серверами?
Это, безусловно, повлияет на производительность, которая может увеличиваться или уменьшаться в зависимости от конфигурации SAN, но почти наверняка не останется такой же. В зависимости от конфигурации вы можете получить более качественные, более быстрые диски с большим объемом кеша в лучших режимах RAID, работающие по более быстрым каналам с несколькими путями - или же это может пойти другим путем.
По сути, все зависит от того, сколько времени, денег и опыта у этого парня, но нечего бояться, если у него всего этого достаточно.
Это можно сделать, но это то, что нужно делать с открытыми глазами. Кому-то действительно нужно провести достаточный мониторинг производительности существующего сервера базы данных, чтобы выяснить, как он работает сейчас, а затем сравнить эти показатели с централизованным хранилищем. Вы могли бы быть в порядке. Или вы уже могли быть узким местом в существующей подсистеме ввода-вывода хранилища, и добавление нескольких шпинделей решит эту проблему.
Чтобы дать вам некоторое представление о том, о чем я говорю, если ваше существующее хранилище представляет собой зеркальную пару из 15 КБ дисков, разумно ожидать от 150 до 500 одновременных операций ввода-вывода в зависимости от точных шаблонов доступа (очень случайным будет ниже, но ваши процессы резервного копирования / экспорта БД могут быть последовательными и, следовательно, выше). Если центральное хранилище состоит из 24 дисков по 15 КБ, вы можете рассчитывать на выполнение от 3000 до 8000 одновременных операций ввода-вывода (при желании сети хранения). В зависимости от того, с чем еще вы конкурируете, ваша база данных может иметь гораздо больший запас по вводу-выводу.
Но чтобы быть уверенным, вам нужно выяснить свои текущие показатели.