Имя: Пароль:
IT
 
Кластеры 1с и MS SQL. Как организовать?
0 Stormicon
 
22.07.13
10:29
По сабжу, есть оборудование:
Два идентичных физических сервера с 512 Гб оперативки, и 4 процами каждый. На каждом поднят Hyper-V. Есть хранилище информации на отдельном железе с 1Gb х 4. Требуется:
Поднять отказоустойчивый кластер на основе виртуальных машин. Разумеется, без потери скорости работы одиночных серверов.
1 modestry
 
22.07.13
11:55
ни как
2 Lama12
 
22.07.13
12:15
(0)А в чем вопрос?
На сате микрософт есть инструкции как сделать кластер СУБД. Как сделать кластер Windows server там тоже есть статьи.
Только отказоустойчивость в такой конфигурации будет больше смахивать на устойчивую отказчивость.
У нас на этих кластерах проджект сервер поднят. На более мощных машинах.
Лучше б мы этого не делали.
3 Stormicon
 
22.07.13
14:24
(2) Вопрос в том, какую конфигурацию выбрать. Проблема в том, что mssql 2012 standart и allwais on сделать не получится. Как  организовать возможность распределения нагрузки с одновременной отказоустойчивостью?
4 rozer76
 
22.07.13
14:38
(3) с микрософтом выйдет только с отказоустойчивостью - один упал, другой - поднялся :) Только нормальный NAS нужен для баз и "кворума"
5 Stormicon
 
22.07.13
14:44
Хорошо. Если как вариант, делать распределение нагрузки вручную - через два экземпляра sql по одному на каждом физическом сервере, два кластера 1с для работы с ними, в каждом кластере 1с 2 виртуалки, по одной на каждой из физических машин?
6 Stormicon
 
22.07.13
14:45
+(5) Допустим, отказоустойчивость за счет слепков виртуалок для скуля, плюс схема полного бэкапа с бэкапом логов (5)
7 krbIso
 
22.07.13
14:58
нафуя такие извращения? у заказчика есть какие то требования к отказоустойчивости?
8 Stormicon
 
22.07.13
15:02
(7) Разумеется. Требуется, чтобы при любом плановом/неплановом отключении любого из серверов была возможность поднять работу в течение 10-60 минут на втором.
9 Sammo
 
22.07.13
15:20
Скуль - логшиппинг или зеркалирование.
Зависит от терпимой просадки в скорости и от того - сколько времени до момента сбоя согласен потерять заказчик (например, логшиппинг каждые 5 минут)
Насколько я помню - в 2008 зеркалирование было не во всех версиях скуля. Не факт, что было в станларте
10 Stormicon
 
22.07.13
15:25
логшиппинг - это просадка в производительности, для 1-2 баз в 30-40Gb это не страшно конечно, но когда их 6-7... Проще ставить отдельные экземпляры. Поправьте, если неправ.
11 упс
 
23.07.13
04:25
(10) не прав. Лог-шиппинг - никакой просадки. При зеркалировании возможны, но если железо на обеих машинах примерно одинаково, вы их не заметите.
12 Sammo
 
модератор
23.07.13
07:04
(11) зависит синхронное асинхронное.
Но еще раз обращаю внимание - зеркалирование - это может быть более дорогая лицензия
Просадки при логшиппинге в рабочей нет. Но надо думать - как массово менять данные. Например, если база 500 гигов и ты массово перепроводишь документы с начала периода, то размер логов будет ... немаленький.
13 Stormicon
 
23.07.13
07:39
(11) (12) В принципе, есть возможность выделить отдельную raid0 лунку для копирования логов. Фактически она итак будет использоваться для снимков лога между полными бэкапами.
14 упс
 
23.07.13
07:58
(12) в синхронном, на одинаковом железе? просадку, скорее всего, никто и не заметит. В асинхронном - на любом железе не заметят. Синхронное зеркалирование доступно начиная со Standard'a, асинхронное - только Enterprise.
15 упс
 
23.07.13
08:00
(13) raid0? Для бэкапов? И лишить себя возможности восстановления на любой момент времени из-за выхода из строя одного диска? Успехов.
16 Stormicon
 
23.07.13
08:04
а кто сказал, что они будут там постоянно храниться? это просто суточные логи межуд бэкапами, плюс с копированием на хранилище. нулевой сделан для скорости.
17 Strogg
 
23.07.13
08:05
А чо именно кластер? На двух серваках можно поставить покопии сиквела и настроить зеркалку. На одном из них - поднять кластера 1С. Тока там надо смотреть, какая база в активе находится. Чтоб знать как ему работать - через шаред мемори, или через тспип. Вроде норм должно быть.
А, ну и третий экземпляр сиквел-экспресс поставить следящим каким-нить. Так вроде норм должно быть. Что-нить можно замутить на виртуалке. Ну, вместе с админскими штучками типа райда и тепе.
18 Stormicon
 
23.07.13
08:12
Вообще, есть желание использовать по максимуму оба сервера. Поэтому и рассматривается кластеризация. Можно вообще не заморачиваясь на кластеры и т.п. взять и поставить каждый сервер по отдельности и пусть там крутятся разные базы. виртуалка скуля, виртуалка 1с и виртуалка терминала
19 упс
 
23.07.13
08:28
(17) а в чём смысл следящего сервера, если SQL Server используется только для 1С? Всё равно придётся базы перепрописывать в консоли, если основной SQL сдохнет.
ИМХО, следящий сервер для 1С не нужен - от него вреда может быть больше. Вполне возможна ситуация, когда по какой-то причине отвалятся зеркальный и следящий сервера, а основной останется живым и доступным - в этом случае зеркальная база на нём так же станет недоступной, до тех пор пока зеркало или следящий не оживут.
(18) кластер - он только для отказоустойчивости, активна у вас будет только одна нода, вторая в это время будет просто ждать пока первая сдохнет, чтобы самой поработать.
20 Stormicon
 
23.07.13
08:56
(19) Ок. Как тебе такая конфигурация:
Машина 1
1. Терминал
2. 1С сервер кластер1 (основной сервер кластера)
3. 1с сервер кластер2 (резервный сервер кластера)
4. Скуль-сервер с двумя экземплярами, один рабочий для данной машины, второй резервный для второй с лог-шиппингом

Машина 2
1. Терминал
2. 1С сервер кластер1 (резервный сервер кластера)
3. 1с сервер кластер2 (основной сервер кластера)
4. Скуль-сервер с двумя экземплярами, один рабочий для данной машины, второй резервный для второй с лог-шиппингом
21 gallam
 
23.07.13
09:23
(0)
http://softpoint.ru/products_id15.htm
Есть возможность сделать кластер и отказоустойчивый и с распределением нагрузки.
Вопрос не по сабжу:
упс, Lamo2, Sammo и прочие - у всех банеры на мисте не отображаются? Сейчас же активная реклама как раз такого решения идет?
22 Stormicon
 
23.07.13
09:27
(21) ну вот вместо логшиппинга сейчас поднимаю этот вариант на синхронном режиме
23 упс
 
23.07.13
09:38
(21)Ну, во-первых, у этого решения:

"Ограничения:
 - MS SQL 2012 Enterprise Edition.
 - Более Windows Server 2008 R2 Enterprise Edition.
"
а в (3) написано, что у Stormicon sql standard
А во-вторых, лично я про решение Softpoint'a знаю только то, что оно есть и вроде как работает. А как работает кластер, зеркало и лог-шиппинг знаю не понаслышке, поэтому могу по ним что-то рассказать.
24 упс
 
23.07.13
09:39
(20) зачем на каждом два экземпляра sql server'a для лог-шиппинга? Базы участвующие и не участвующие в лог-шиппинге спокойно могут на одном экземпляре уживаться.
25 Stormicon
 
23.07.13
09:42
(24) чтобы сделать распределение нагрузки - часть баз на одном сервере как на основной ноде, часть - на другом
26 gallam
 
23.07.13
09:42
(23) Про Standart это да, alwaysOn не применим.
Лог шиппинг мы тоже раньше внедряли - очень сложно на ней кластера стоить (хотя можно).
27 zva
 
23.07.13
09:43
(20) Советую с лицензиями 1С все продумать... При такой схеме нужно 4 лицензии на сервер 1С и 2х Клиентских лицензий.
Конфигурация 1С какая будет? Тонкий и веб клиент поддерживает?
28 Stormicon
 
23.07.13
09:43
1С будет 8.3 стоять, в режиме совместимости с 8.2, количество лицензий глубоко по барабану, ключей хватает.
29 Stormicon
 
23.07.13
09:45
(26) насколько я вижу в программе установки SQL alwaysOn применим в синхронном режиме. Вот думаю вместо логшиппинга его сделать. Только опять нужен кластер Windows
30 gallam
 
23.07.13
09:47
(29) Синхронный режим может приводить к замедлению изменений данных, почему не асинхронный?
31 Stormicon
 
23.07.13
09:50
(30) для асиинхронного нужен Enterprise