Кластеры 1с и MS SQL. Как организовать? #673851

По сабжу, есть оборудование: Два идентичных физических сервера с 512 Гб оперативки, и 4 процами каждый. На каждом поднят Hyper-V. Есть хранилище информации на отдельном железе с 1Gb х 4. Требуется: Поднять отказоустойчивый кластер на основе виртуальных машин. Разумеется, без потери скорости работы одиночных серверов.

ни как

А в чем вопрос? На сате микрософт есть инструкции как сделать кластер СУБД. Как сделать кластер Windows server там тоже есть статьи. Только отказоустойчивость в такой конфигурации будет больше смахивать на устойчивую отказчивость. У нас на этих кластерах проджект сервер поднят. На более мощных машинах. Лучше б мы этого не делали.

Вопрос в том, какую конфигурацию выбрать. Проблема в том, что mssql 2012 standart и allwais on сделать не получится. Как  организовать возможность распределения нагрузки с одновременной отказоустойчивостью?

с микрософтом выйдет только с отказоустойчивостью - один упал, другой - поднялся :) Только нормальный NAS нужен для баз и "кворума"

Хорошо. Если как вариант, делать распределение нагрузки вручную - через два экземпляра sql по одному на каждом физическом сервере, два кластера 1с для работы с ними, в каждом кластере 1с 2 виртуалки, по одной на каждой из физических машин?

+ Допустим, отказоустойчивость за счет слепков виртуалок для скуля, плюс схема полного бэкапа с бэкапом логов

нафуя такие извращения? у заказчика есть какие то требования к отказоустойчивости?

Разумеется. Требуется, чтобы при любом плановом/неплановом отключении любого из серверов была возможность поднять работу в течение 10-60 минут на втором.

Скуль - логшиппинг или зеркалирование. Зависит от терпимой просадки в скорости и от того - сколько времени до момента сбоя согласен потерять заказчик (например, логшиппинг каждые 5 минут) Насколько я помню - в 2008 зеркалирование было не во всех версиях скуля. Не факт, что было в станларте

логшиппинг - это просадка в производительности, для 1-2 баз в 30-40Gb это не страшно конечно, но когда их 6-7... Проще ставить отдельные экземпляры. Поправьте, если неправ.

не прав. Лог-шиппинг - никакой просадки. При зеркалировании возможны, но если железо на обеих машинах примерно одинаково, вы их не заметите.

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

В принципе, есть возможность выделить отдельную raid0 лунку для копирования логов. Фактически она итак будет использоваться для снимков лога между полными бэкапами.

в синхронном, на одинаковом железе? просадку, скорее всего, никто и не заметит. В асинхронном - на любом железе не заметят. Синхронное зеркалирование доступно начиная со Standard'a, асинхронное - только Enterprise.

raid0? Для бэкапов? И лишить себя возможности восстановления на любой момент времени из-за выхода из строя одного диска? Успехов.

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

А чо именно кластер? На двух серваках можно поставить покопии сиквела и настроить зеркалку. На одном из них - поднять кластера 1С. Тока там надо смотреть, какая база в активе находится. Чтоб знать как ему работать - через шаред мемори, или через тспип. Вроде норм должно быть. А, ну и третий экземпляр сиквел-экспресс поставить следящим каким-нить. Так вроде норм должно быть. Что-нить можно замутить на виртуалке. Ну, вместе с админскими штучками типа райда и тепе.

Вообще, есть желание использовать по максимуму оба сервера. Поэтому и рассматривается кластеризация. Можно вообще не заморачиваясь на кластеры и т.п. взять и поставить каждый сервер по отдельности и пусть там крутятся разные базы. виртуалка скуля, виртуалка 1с и виртуалка терминала

а в чём смысл следящего сервера, если SQL Server используется только для 1С? Всё равно придётся базы перепрописывать в консоли, если основной SQL сдохнет. ИМХО, следящий сервер для 1С не нужен - от него вреда может быть больше. Вполне возможна ситуация, когда по какой-то причине отвалятся зеркальный и следящий сервера, а основной останется живым и доступным - в этом случае зеркальная база на нём так же станет недоступной, до тех пор пока зеркало или следящий не оживут. кластер - он только для отказоустойчивости, активна у вас будет только одна нода, вторая в это время будет просто ждать пока первая сдохнет, чтобы самой поработать.

Ок. Как тебе такая конфигурация: Машина 1 1. Терминал 2. 1С сервер кластер1 (основной сервер кластера) 3. 1с сервер кластер2 (резервный сервер кластера) 4. Скуль-сервер с двумя экземплярами, один рабочий для данной машины, второй резервный для второй с лог-шиппингом Машина 2 1. Терминал 2. 1С сервер кластер1 (резервный сервер кластера) 3. 1с сервер кластер2 (основной сервер кластера) 4. Скуль-сервер с двумя экземплярами, один рабочий для данной машины, второй резервный для второй с лог-шиппингом

Есть возможность сделать кластер и отказоустойчивый и с распределением нагрузки. Вопрос не по сабжу: упс, Lamo2, Sammo и прочие - у всех банеры на мисте не отображаются? Сейчас же активная реклама как раз такого решения идет?

ну вот вместо логшиппинга сейчас поднимаю этот вариант на синхронном режиме

Ну, во-первых, у этого решения: "Ограничения:  - MS SQL 2012 Enterprise Edition.  - Более Windows Server 2008 R2 Enterprise Edition. " а в написано, что у sql standard А во-вторых, лично я про решение Softpoint'a знаю только то, что оно есть и вроде как работает. А как работает кластер, зеркало и лог-шиппинг знаю не понаслышке, поэтому могу по ним что-то рассказать.

зачем на каждом два экземпляра sql server'a для лог-шиппинга? Базы участвующие и не участвующие в лог-шиппинге спокойно могут на одном экземпляре уживаться.

чтобы сделать распределение нагрузки - часть баз на одном сервере как на основной ноде, часть - на другом

Про Standart это да, alwaysOn не применим. Лог шиппинг мы тоже раньше внедряли - очень сложно на ней кластера стоить (хотя можно).

Советую с лицензиями 1С все продумать... При такой схеме нужно 4 лицензии на сервер 1С и 2х Клиентских лицензий. Конфигурация 1С какая будет? Тонкий и веб клиент поддерживает?

1С будет 8.3 стоять, в режиме совместимости с 8.2, количество лицензий глубоко по барабану, ключей хватает.

насколько я вижу в программе установки SQL alwaysOn применим в синхронном режиме. Вот думаю вместо логшиппинга его сделать. Только опять нужен кластер Windows

Синхронный режим может приводить к замедлению изменений данных, почему не асинхронный?

для асиинхронного нужен Enterprise