Отказоустойчивое решение для двух серверов СУБД.

Ответить
cobion
Почетный гражданин
Сообщения: 176
Зарегистрирован: 22 апр 2016 07:26

Отказоустойчивое решение для двух серверов СУБД.

Сообщение cobion »

Доброго времени суток Уважаемые коллеги. Внедряем решение по оптимизации клиент-серверной архитектуры для 1С+СУБД. Общее количество пользователей работы с 1С приложением от 180 до 400. Для данного решения есть три физических, подчеркну физических (никакой виртуализации) сервера.

Каждый сервер содержит:

Памяти 256 Gb, 2 CPU по 8 ядер каждый 3 GHz.

Диски NVme Optane PCIe для всех 4 баз и TempDB.

Два купленных экземпляра SQL Server 2014 и 2016 редакции Standard

Два купленных экземпляра Windows Server 2016 редакции Standard

Один из серверов будет выполнять роль сервера 1С, второй и третий роль сервера СУБД.
Для решения задач оптимизации все вроде бы как решаемо. Но с точки зрения отказоустойчивости, есть некоторого рода вопросы:

1.Возможно ли внедрить какое либо решение по доступности для серверов СУБД ? Понятно что редакция SQL Standard поддерживает технология FCI- кластеризацию instance, но как быть с синхронизацией локальных Nvme PCIe дисков между двумя серверами, где собственно и будут располагаться базы,ведь такого рода решения возможны только в AlwaysON групп доступности в SQL редакции Enterprise- а это уже совсем другие деньги ?

2.Либо отдельное решение по синхронизации баз на локальных дисках между физическими серверами ?

3.Второй сервер СУБД как холодный резерв- слишком дорогое удовольствие за пассивный простой железа.

Спасибо.
Аватара пользователя
Алексей Максимов
Администратор сайта
Сообщения: 572
Зарегистрирован: 14 сен 2012 06:50
Откуда: г.Сыктывкар
Контактная информация:

Re: Отказоустойчивое решение для двух серверов СУБД.

Сообщение Алексей Максимов »

Здравствуйте, Дмитрий.
...никакой виртуализации...
Напрасно. Не стоит верить в широко-распространённые байки про "1С работает нормально только на железе". Разумеется, я понимаю, что для многих это вопрос религии, и пытаться представить альтернативную точку зрения этим сектантам - занятие неблагодарное.

Однако, на мой взгляд, если бы к этим трём серверам добавить адаптеры HBA + надёжную СХД (желательно с дублированными аппаратными компонентами) в качестве общего хранилища, то можно было бы на базе виртуализации построить действительно высоко-доступное и гибкое решение. Такое решение в перспективе гораздо проще будет масштабировать с учётом растущих аппетитов "бизнеса". К тому же, при правильной настройке, выход из строя любого из серверов (даже двух из трёх имеющихся) не будет приводить к полной остановке сервиса, а лишь к понижению его производительности. И напротив, если "бизнес" начнёт сужаться, то, в случае необходимости, можно будет без особых усилий высвободить сервер, например, для его дальнейшей продажи. Где виртуализация, там гибкость и повышение доступности в одном флаконе.

Если мы говорим про 1С:Предприятие v8, то осмелюсь предположить, что для ресурсов сервера приложений 1С такой дури на выделенном железном сервере будет попросту избыточно. И опять же, перераспределить эту дурь с условием отказа от виртуализации будет весьма из разряда "миссия невыполнима". Если не считать это проблемой и говорить только о серверах СУБД то, помимо классической кластеризации Failover Cluster с общим хранилищем в Standard есть Log Shipping, которым можно попробовать настроить отсылку логов БД на сервер холодного резерва. Но это, опять же, неэффективное использование железа, да и без костылей обеспечивать такую "высокую доступность" наверняка будет непросто.
molik
Постоялец
Сообщения: 64
Зарегистрирован: 18 май 2017 05:19

Re: Отказоустойчивое решение для двух серверов СУБД.

Сообщение molik »

Напрасно. Не стоит верить в широко-распространённые байки про "1С работает нормально только на железе". Разумеется, я понимаю, что для многих это вопрос религии, и пытаться представить альтернативную точку зрения этим сектантам - занятие неблагодарное.
1. а если на сервере работает сервис(1С или sql), которые требуют максимальной производительность, есть смысл виртуализировать его на сервере, где будет по сути одна ВМ с этим сервисом?

2. если выбирать между гипервизорами, то что лучше использовать hyper-v или qemu/kvm ?

3. в случае использования виртуализации, как лучше сделать отказоустойчивость: с помощью 'sql failover clustering' или на уровне гипервизоров в кластере, где одна ВМ будел ходить по гипервизорам в случае проблем с железом, но в этом случае для хранилиза баз придётся использовать диск vhdx, а в случае с 'sql failover clustering' сырые данные на разделе хранилища?
Ответить

Вернуться в «SQL Server»