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

ни как

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(21)Ну, во-первых, у этого решения:

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

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

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

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

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

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

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

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

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