Доброго времени суток Уважаемые коллеги. Внедряем решение по оптимизации клиент-серверной архитектуры для 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: Отказоустойчивое решение для двух серверов СУБД.
Здравствуйте, Дмитрий.
Однако, на мой взгляд, если бы к этим трём серверам добавить адаптеры HBA + надёжную СХД (желательно с дублированными аппаратными компонентами) в качестве общего хранилища, то можно было бы на базе виртуализации построить действительно высоко-доступное и гибкое решение. Такое решение в перспективе гораздо проще будет масштабировать с учётом растущих аппетитов "бизнеса". К тому же, при правильной настройке, выход из строя любого из серверов (даже двух из трёх имеющихся) не будет приводить к полной остановке сервиса, а лишь к понижению его производительности. И напротив, если "бизнес" начнёт сужаться, то, в случае необходимости, можно будет без особых усилий высвободить сервер, например, для его дальнейшей продажи. Где виртуализация, там гибкость и повышение доступности в одном флаконе.
Если мы говорим про 1С:Предприятие v8, то осмелюсь предположить, что для ресурсов сервера приложений 1С такой дури на выделенном железном сервере будет попросту избыточно. И опять же, перераспределить эту дурь с условием отказа от виртуализации будет весьма из разряда "миссия невыполнима". Если не считать это проблемой и говорить только о серверах СУБД то, помимо классической кластеризации Failover Cluster с общим хранилищем в Standard есть Log Shipping, которым можно попробовать настроить отсылку логов БД на сервер холодного резерва. Но это, опять же, неэффективное использование железа, да и без костылей обеспечивать такую "высокую доступность" наверняка будет непросто.
Напрасно. Не стоит верить в широко-распространённые байки про "1С работает нормально только на железе". Разумеется, я понимаю, что для многих это вопрос религии, и пытаться представить альтернативную точку зрения этим сектантам - занятие неблагодарное....никакой виртуализации...
Однако, на мой взгляд, если бы к этим трём серверам добавить адаптеры HBA + надёжную СХД (желательно с дублированными аппаратными компонентами) в качестве общего хранилища, то можно было бы на базе виртуализации построить действительно высоко-доступное и гибкое решение. Такое решение в перспективе гораздо проще будет масштабировать с учётом растущих аппетитов "бизнеса". К тому же, при правильной настройке, выход из строя любого из серверов (даже двух из трёх имеющихся) не будет приводить к полной остановке сервиса, а лишь к понижению его производительности. И напротив, если "бизнес" начнёт сужаться, то, в случае необходимости, можно будет без особых усилий высвободить сервер, например, для его дальнейшей продажи. Где виртуализация, там гибкость и повышение доступности в одном флаконе.
Если мы говорим про 1С:Предприятие v8, то осмелюсь предположить, что для ресурсов сервера приложений 1С такой дури на выделенном железном сервере будет попросту избыточно. И опять же, перераспределить эту дурь с условием отказа от виртуализации будет весьма из разряда "миссия невыполнима". Если не считать это проблемой и говорить только о серверах СУБД то, помимо классической кластеризации Failover Cluster с общим хранилищем в Standard есть Log Shipping, которым можно попробовать настроить отсылку логов БД на сервер холодного резерва. Но это, опять же, неэффективное использование железа, да и без костылей обеспечивать такую "высокую доступность" наверняка будет непросто.
Re: Отказоустойчивое решение для двух серверов СУБД.
1. а если на сервере работает сервис(1С или sql), которые требуют максимальной производительность, есть смысл виртуализировать его на сервере, где будет по сути одна ВМ с этим сервисом?Напрасно. Не стоит верить в широко-распространённые байки про "1С работает нормально только на железе". Разумеется, я понимаю, что для многих это вопрос религии, и пытаться представить альтернативную точку зрения этим сектантам - занятие неблагодарное.
2. если выбирать между гипервизорами, то что лучше использовать hyper-v или qemu/kvm ?
3. в случае использования виртуализации, как лучше сделать отказоустойчивость: с помощью 'sql failover clustering' или на уровне гипервизоров в кластере, где одна ВМ будел ходить по гипервизорам в случае проблем с железом, но в этом случае для хранилиза баз придётся использовать диск vhdx, а в случае с 'sql failover clustering' сырые данные на разделе хранилища?
