Конфигурация под 1c 8.2 УПП, MSSQL, терминал
Модераторы: Trinity admin`s, Free-lance moderator`s
Конфигурация под 1c 8.2 УПП, MSSQL, терминал
Добрый день.
Стоит задача за год перевести контору с 1с 7.7 на 1с 8.2. Пользователей на данный момент около 150, и их количество постепенно растет (систему рассчитываю на 150-200 пользователей).
Планируется поставить 1c 8.2 конфигурацию УПП, MSSQL (2008 или 2012), и пустить все это дело через терминал (или лучше через тонкого клиента?).
Прошу посоветовать под это дело железо. Хотелось бы иметь систему с полной отказоустойчивостью.
На данный момент надумал следующее:
1. Два сервера Intel SR1690WBR c 2xXEON X5650 2660/6.4GT/12M, 8x8Gb RAM, 2xST500NM0011, контроллер типа LSI 9200-8e. На сервере XEN c виртуалками под SQL, под 1C, под терминал. Как их лучше делить? Стоит ли делить сервер 1с и SQL?
2. Две полки двухконтроллерных, типа Infortrend ESDS S16S-R2240 с 11 (пока) SAS винтами (300Gb) под RAID 10 + Hot Swap. Это под базу.
3. Ну и для соединения всего этого два SAS-свитча LSI 6160. SAS решение выбрано, так как у FC большая латентность, плюс оборудование стоит в одном шкафу, и расстояния не нужны, ну и дешевле значительно получается решение на SAS, чем на FC.
Можете покритиковать решение, предложить что-то свое? Начальство требует, а у самого в этом деле опыта не хватает.
Стоит задача за год перевести контору с 1с 7.7 на 1с 8.2. Пользователей на данный момент около 150, и их количество постепенно растет (систему рассчитываю на 150-200 пользователей).
Планируется поставить 1c 8.2 конфигурацию УПП, MSSQL (2008 или 2012), и пустить все это дело через терминал (или лучше через тонкого клиента?).
Прошу посоветовать под это дело железо. Хотелось бы иметь систему с полной отказоустойчивостью.
На данный момент надумал следующее:
1. Два сервера Intel SR1690WBR c 2xXEON X5650 2660/6.4GT/12M, 8x8Gb RAM, 2xST500NM0011, контроллер типа LSI 9200-8e. На сервере XEN c виртуалками под SQL, под 1C, под терминал. Как их лучше делить? Стоит ли делить сервер 1с и SQL?
2. Две полки двухконтроллерных, типа Infortrend ESDS S16S-R2240 с 11 (пока) SAS винтами (300Gb) под RAID 10 + Hot Swap. Это под базу.
3. Ну и для соединения всего этого два SAS-свитча LSI 6160. SAS решение выбрано, так как у FC большая латентность, плюс оборудование стоит в одном шкафу, и расстояния не нужны, ну и дешевле значительно получается решение на SAS, чем на FC.
Можете покритиковать решение, предложить что-то свое? Начальство требует, а у самого в этом деле опыта не хватает.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Re: Конфигурация под 1c 8.2 УПП, MSSQL, терминал
Легко.Dr. Grue писал(а):Можете покритиковать решение, предложить что-то свое? Начальство требует, а у самого в этом деле опыта не хватает.
1. Зачем две системы хранения? Думаете от этого у вас повысится надежность решения?
2. Зачем САС коммутаторы? Планируете подключать к СХД бОльше 4-х серверов?
3. Из каких соображений выбрано всего два сервера?
Вопросы:
4. Размеры баз какие?
5. Как планируется организовать логическую структуру 1С?
6. Где будут сервера приложений, сервера терминалов?
7. Максимальное время простоя можете сказать?
8. Куда и как будете бекапить?
9. Готовы ли выделить бюджет в районе 50-60 тыс.$ на решение без софта?
Re: Конфигурация под 1c 8.2 УПП, MSSQL, терминал
1. Да, полагаю, что повысится. Планирую использовать по возможности удаленную репликацию, а если это невозможно, просто зеркалировать через софтовый рэйд на сервере.
2. Коммутаторы взяты так же из соображений надежности, для подключения "каждого к каждому". Каждый из контроллеров полки к каждому коммутатору, и каждый сервер к каждому коммутатору.
3. А сколько Вы предлагаете? Выбрано не то, чтобы "всего" два. А "аж" два. Откровенно говоря, один из них (без САС контроллера) уже есть, причем довольно свежий. И хотелось бы его использовать. А второй выбран такой же, а не новый из соображений возможности соединения их в кластер в XEN.
4. Сложно сказать, восьмерка не использовалась. И к марту только планируется запустить ее на 10 человек. В 7.7 около 20 баз, общим размером в 70 Гб. В 8.2 планируется одна база по возможности. Размер примерно такой: 5000 контагентов, 5000 номенклатуры и 500-1000 документов в день.
5. Не совсем понимаю, что именно имеется в виду под логической структурой?
6. В виртуалках на обоих серверах. Сервер приложения и сервер БД - на Win2008R2, терминал - Win2003R2. Расположение зависит от того, сколько под них надо будет выделить.
7. Хочется иметь полное зеркалирование, и в работе непосредственно оборудования простоев не иметь.
8. Бэкапить скорее всего по ночам средствами Acronis на имеющееся файловое хранилище Thecus N16000.
9. Отталкиваться хотелось бы от потребностей, а не от бюджета. 50-60 тыс, наверное, многовато, но если это того стоит, будем убеждать.
2. Коммутаторы взяты так же из соображений надежности, для подключения "каждого к каждому". Каждый из контроллеров полки к каждому коммутатору, и каждый сервер к каждому коммутатору.
3. А сколько Вы предлагаете? Выбрано не то, чтобы "всего" два. А "аж" два. Откровенно говоря, один из них (без САС контроллера) уже есть, причем довольно свежий. И хотелось бы его использовать. А второй выбран такой же, а не новый из соображений возможности соединения их в кластер в XEN.
4. Сложно сказать, восьмерка не использовалась. И к марту только планируется запустить ее на 10 человек. В 7.7 около 20 баз, общим размером в 70 Гб. В 8.2 планируется одна база по возможности. Размер примерно такой: 5000 контагентов, 5000 номенклатуры и 500-1000 документов в день.
5. Не совсем понимаю, что именно имеется в виду под логической структурой?
6. В виртуалках на обоих серверах. Сервер приложения и сервер БД - на Win2008R2, терминал - Win2003R2. Расположение зависит от того, сколько под них надо будет выделить.
7. Хочется иметь полное зеркалирование, и в работе непосредственно оборудования простоев не иметь.
8. Бэкапить скорее всего по ночам средствами Acronis на имеющееся файловое хранилище Thecus N16000.
9. Отталкиваться хотелось бы от потребностей, а не от бюджета. 50-60 тыс, наверное, многовато, но если это того стоит, будем убеждать.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Re: Конфигурация под 1c 8.2 УПП, MSSQL, терминал
Вы ошибаетесь. В классической схеме с одним двухконтроллероным массивом + сервером резервного копирования вы обеспечите надежность от физического и логического сбоя. Двумя, тремя или десятком СХД вы в лучшем случае обеспечите защиту от сбоя СХД.Dr. Grue писал(а):1. Да, полагаю, что повысится. Планирую использовать по возможности удаленную репликацию, а если это невозможно, просто зеркалировать через софтовый рэйд на сервере.
тут вы тоже ошибаетесь. В современных СХД наружу можно получить 4-е САС порта, что вполне хватит для построения кластера. Внешние коммутаторы нужны, если надо бОльше 4-х серверов.2. Коммутаторы взяты так же из соображений надежности, для подключения "каждого к каждому". Каждый из контроллеров полки к каждому коммутатору, и каждый сервер к каждому коммутатору.
Классически на 150--200 пользователей 1С вам надо:3. А сколько Вы предлагаете? Выбрано не то, чтобы "всего" два. А "аж" два. Откровенно говоря, один из них (без САС контроллера) уже есть, причем довольно свежий. И хотелось бы его использовать. А второй выбран такой же, а не новый из соображений возможности соединения их в кластер в XEN.
1. кластер серверов баз данных с внешней СХД
2. кластер серверов приложений
3. 3-и - 4-е сервера терминалов из расчета одно ядро на 2-а пользователя. 100 логических ядер или 50-ть физических ядер, это 6-8 8-ми ядерных физических процессора. Что не сможет уложиться в одну 2-х процессорную машинку.
это совсем другие цифры, но не 200 пользователей.4. Сложно сказать, восьмерка не использовалась. И к марту только планируется запустить ее на 10 человек. В 7.7 около 20 баз, общим размером в 70 Гб. В 8.2 планируется одна база по возможности. Размер примерно такой: 5000 контагентов, 5000 номенклатуры и 500-1000 документов в день.
чуть выше написано5. Не совсем понимаю, что именно имеется в виду под логической структурой?
в 1С это ничем не обеспечить. В кластере базы данных при сбое все равно нужно время на поднятие базы на втором сервере.7. Хочется иметь полное зеркалирование, и в работе непосредственно оборудования простоев не иметь.
восстанавливаться на другое железо пробовали?8. Бэкапить скорее всего по ночам средствами Acronis на имеющееся файловое хранилище Thecus N16000.
Итак, на сколько пользователей мы ориентируемся? Кластер HA строим на XEN? Надеюсь не на бесплатном?9. Отталкиваться хотелось бы от потребностей, а не от бюджета. 50-60 тыс, наверное, многовато, но если это того стоит, будем убеждать.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Re: Конфигурация под 1c 8.2 УПП, MSSQL, терминал
Как я все это вижу. Для запуска понадобится пара одинаковых (очень желательно) серверов + внешняя СХД. На нем делать пилотный проект. К концу 13-го года в процессе запуска и переезда готовить деньги порядка 50-70 тысяч $ на докупку серверов + строить нормальную СРК на внешний сервер СРК. Сервера можно в принципе взять наши. По процессорам парочку 6-ти ядерников, чтобы потом не менять обратно. А СХД я бы рекомендовал посмотреть на ИБМ ДС3524. Вполне солидно и не шибко накладно по деньгам. Минимально на этом можно сделать кластер под виртуализацию.Dr. Grue писал(а):4. Сложно сказать, восьмерка не использовалась. И к марту только планируется запустить ее на 10 человек. В 7.7 около 20 баз, общим размером в 70 Гб. В 8.2 планируется одна база по возможности. Размер примерно такой: 5000 контагентов, 5000 номенклатуры и 500-1000 документов в день.
Вариант пришлем в профильную почту.
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Re: Конфигурация под 1c 8.2 УПП, MSSQL, терминал
С SQL базой резервирование БД можно сделать и без СХД.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Re: Конфигурация под 1c 8.2 УПП, MSSQL, терминал
Если сейчас на 7-ке база 70ГБ, считай на 8-ке она станет раза в 3-4 больше. Представь себе, сколько времени она будет синхронизироваться при активной работе 200 пользователей? И какой в этом тайный смысл?gs писал(а):С SQL базой резервирование БД можно сделать и без СХД.
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Re: Конфигурация под 1c 8.2 УПП, MSSQL, терминал
Ну так она же не каждый раз полностью синхронизироваться будет
Я имел в виду лог шиппинг или датабейз мирроринг. Некоторый плюс в том, что это два экземпляра БД и похериться разом им сложнее, чем кластеризованной базе.
Я имел в виду лог шиппинг или датабейз мирроринг. Некоторый плюс в том, что это два экземпляра БД и похериться разом им сложнее, чем кластеризованной базе.
- Inna
- Сотрудник Тринити
- Сообщения: 227
- Зарегистрирован: 01 ноя 2008, 11:03
- Откуда: Екатеринбург
- Контактная информация:
Re: Конфигурация под 1c 8.2 УПП, MSSQL, терминал
Dr. Grue,
вариант кластера с внешней СХД в профильной почте!
вариант кластера с внешней СХД в профильной почте!
Re: Конфигурация под 1c 8.2 УПП, MSSQL, терминал
Конфигурацию получил, спасибо.
Но не обеспечу высокой доступности, а данный функционал, как я уже писал, нам необходим.Stranger03 писал(а):В классической схеме с одним двухконтроллероным массивом + сервером резервного копирования вы обеспечите надежность от физического и логического сбоя
Stranger03 писал(а):В современных СХД наружу можно получить 4-е САС порта, что вполне хватит для построения кластера. Внешние коммутаторы нужны, если надо бОльше 4-х серверов.
Не все современные СХД имеют четыре sas, приведенный мной имеет только два. С другой стороны, ввод новых компонентов (коммутатора) в работающую схему часто чреват различными коллизиями, которые могут привести к достаточно длительным простоям в предоставлении сервиса, что не является для нас приемлимым. Именно поэтому в схеме, предложенной мной, присутствует избыточность на данный момент.Stranger03 писал(а):К концу 13-го года в процессе запуска и переезда готовить деньги порядка 50-70 тысяч $ на докупку серверов
Можно узнать, откуда такие данные? Кроме того, вопрос о использовании терминального сервера для 1с8 пока остается открытым, так как теоретически преимущество терминального клиента над тонким или веб-клиентом сомнительно.Stranger03 писал(а):Классически на 150--200 пользователей 1С вам надо:…
…из расчета одно ядро на 2-а пользователя..
Это одна из причин использования XEN.Stranger03 писал(а):в 1С это ничем не обеспечить. В кластере базы данных при сбое все равно нужно время на поднятие базы на втором сервере.
восстанавливали и на другое железо, и на виртуалку с железа, и с виртуалки на железо. Все ОК. А в чем подвох?Stranger03 писал(а):восстанавливаться на другое железо пробовали?
Не могли бы Вы расшифровать понятие «солидность» в данном контексте? И чем плох Infortrend? Какие преимущества одного над другим в приложении к нашей задаче? Минусы я вижу в использовании двухдюймовых винтов (может и не прав), в стоимости лицензии на репликацию, одна марка винтов. Плюс в возможности перехода, если потребуется, на FC без смены полки.Stranger03 писал(а):СХД я бы рекомендовал посмотреть на ИБМ ДС3524. Вполне солидно и не шибко накладно по деньгам
gs писал(а):С SQL базой резервирование БД можно сделать и без СХД.
Stranger03 писал(а):Представь себе, сколько времени она будет синхронизироваться при активной работе 200 пользователей?
Позвольте вмешаться. Резервирование базы данных 1с будет осуществляться на специально выделенный сервер, который у нас уже есть, и которым мы пользуемся уже достаточно давно. Ни о какой синхронизации, о шиппинге речи не идет. Необходимо обеспечить режим высокой доступности, чтобы при выходе из строя любого из компонентов (сервера, СХД или коммутатора) работа базы не была нарушена. Ни резервирование, ни шиппинг, ни дампинг этого не обеспечивают.gs писал(а):Ну так она же не каждый раз полностью синхронизироваться будет
Я имел в виду лог шиппинг или датабейз мирроринг. Некоторый плюс в том, что это два экземпляра БД и похериться разом им сложнее, чем кластеризованной базе.
Правильно ли я понимаю по отсутствию критики на этот счет, что выбор в данном случае SAS Вы поддерживаете?Dr. Grue писал(а):SAS решение выбрано, так как у FC большая латентность, плюс оборудование стоит в одном шкафу, и расстояния не нужны, ну и дешевле значительно получается решение на SAS, чем на FC.
Последний раз редактировалось Dr. Grue 24 дек 2012, 22:10, всего редактировалось 1 раз.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Re: Конфигурация под 1c 8.2 УПП, MSSQL, терминал
Что в вашем понимании высокая доступность? В моем это две площадки в разных зданиях с полным дублированием компонент и четким регламентом восстановления работоспособности. Еще раз, совет, на начальном этапе потратьтесь на одну железку. Для стартапа этого вполне достаточно. Современные СХД вполне надежные.Dr. Grue писал(а):Но не обеспечу высокой доступности, а данный функционал, как я уже писал, нам необходим.
ИБМ ДС3500 имеет. Вместо коммутаторов я бы лично вложил деньги в диски, ибо от их количества напрямую зависит производительность системы в целом.Не все современные СХД имеют четыре sas, приведенный мной имеет только два. С другой стороны, ввод новых компонентов (коммутатора) в работающую схему часто чреват различными коллизиями, которые могут привести к достаточно длительным простоям в предоставлении сервиса, что не является для нас приемлимым. Именно поэтому в схеме, предложенной мной, присутствует избыточность на данный момент.
Из моего опыта, поверьте, очень богатого.Можно узнать, откуда такие данные? Кроме того, вопрос о использовании терминального сервера для 1с8 пока остается открытым, так как теоретически преимущество терминального клиента над тонким или веб-клиентом сомнительно.
Сколько времени у вас займет бекап 200ГБ по сети? А сколько времени у вас займет восстановление? С Акронисом не шибко знаком. Он имеет агенты под Вин, под базы данных? Имеет возможность делать консистентные бекапы?восстанавливали и на другое железо, и на виртуалку с железа, и с виртуалки на железо. Все ОК. А в чем подвох?
Просто посчитайте по деньгам. При прочих равных условиях ИБМ будет не дороже Инфортренда, а о разных фичах можно читать тут: http://blog.trinitygroup.ruНе могли бы Вы расшифровать понятие «солидность» в данном контексте? И чем плох Infortrend? Какие преимущества одного над другим в приложении к нашей задаче? Минусы я вижу в использовании двухдюймовых винтов (может и не прав), в стоимости лицензии на репликацию, одна марка винтов. Плюс в возможности перехода, если потребуется, на FC без смены полки.
Позвольте спросить, какими средствами вы будете это обеспечивать? Вопрос про программные средства.Позвольте вмешаться. Резервирование базы данных 1с будет осуществляться на специально выделенный сервер, который у нас уже есть, и которым мы пользуемся уже достаточно давно. Ни о какой синхронизации, о шиппинге речи не идет. Необходимо обеспечить режим высокой доступности, чтобы при выходе из строя любого из компонентов (сервера, СХД или коммутатора) работа базы не была нарушена. Ни резервирование, ни шиппинг, ни дампинг этого не обеспечивают.
Вполне, но я опять настаиваю, в вашей схеме не нужны коммутаторы. По крайней мере я не вижу в них необходимости. Это лишнее звено. Лучше деньги потратить на другие вещи, бОлее нужные в данном решении.Правильно ли я понимаю по отсутствию критики на этот счет, что выбор в данном случае SAS Вы поддерживаете?
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Re: Конфигурация под 1c 8.2 УПП, MSSQL, терминал
На тему Инфортренда, например вот это: http://infortrend.com/ru/products/model ... B24S-R2240
Есть 4-е САС порта. При подключении к 2-м серверам подключаются по одному линку от каждого контроллера к каждому серверу. Соотв-но 4-х портов вполне достаточно. У ДС3500 можно получить 8-мь САС портов, кстати.
Есть 4-е САС порта. При подключении к 2-м серверам подключаются по одному линку от каждого контроллера к каждому серверу. Соотв-но 4-х портов вполне достаточно. У ДС3500 можно получить 8-мь САС портов, кстати.
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Re: Конфигурация под 1c 8.2 УПП, MSSQL, терминал
У Вас какой-то очень оригинальный подход. Денег нет, но Вы хотите дублировать самую надежную и дорогую часть системы.
Дублирование стораджей конечно вещь полезная, но обычно это делается не от хорошей жизни (когда мало отказоустойчивости одной дублированной железяки) и с очень серьезными обоснованиями.
Зеркалирование стораджей Вам мало что даст в реальности. Это не поможет от логических сбоев (т.к. данные там идентичны), только увеличит цену, сложность и соответственно добавит своих потенциальных глюков.
Если в Вашей конторе бизнес-процессы таковы, что не позволяют простой в 10 минут на переключение на резервную базу, то сделайте обычный кластер с одним стораджем. А для подстраховки поставьте рядом просто аварийный сервер с достаточно мощной дисковой и лейте туда шиппинг. В клиническом случае сможете быстро оттуда запуститься. Это дешевле и эффективнее, чем два стораджа зеркалить.
А вот сторадж лучше двухконтроллерный ИБМ с сервис-паком - его быстро починят, в отличие от инфортренда, на который фирменный сервис отсутствует как класс. Ну и свичи при этом будут без надобности - а это много тысяч долларов.
Дублирование стораджей конечно вещь полезная, но обычно это делается не от хорошей жизни (когда мало отказоустойчивости одной дублированной железяки) и с очень серьезными обоснованиями.
Зеркалирование стораджей Вам мало что даст в реальности. Это не поможет от логических сбоев (т.к. данные там идентичны), только увеличит цену, сложность и соответственно добавит своих потенциальных глюков.
Если в Вашей конторе бизнес-процессы таковы, что не позволяют простой в 10 минут на переключение на резервную базу, то сделайте обычный кластер с одним стораджем. А для подстраховки поставьте рядом просто аварийный сервер с достаточно мощной дисковой и лейте туда шиппинг. В клиническом случае сможете быстро оттуда запуститься. Это дешевле и эффективнее, чем два стораджа зеркалить.
А вот сторадж лучше двухконтроллерный ИБМ с сервис-паком - его быстро починят, в отличие от инфортренда, на который фирменный сервис отсутствует как класс. Ну и свичи при этом будут без надобности - а это много тысяч долларов.
Re: Конфигурация под 1c 8.2 УПП, MSSQL, терминал
To Stranger03:
To Dr. Grue:
Потом коротенько отпишитесь, пожалуйста, тут, как Вам удаcтся добиться отсутствия любых перерывов в работе при отказах оборудования. А то поставщики HA-решений совсем другие бюджеты называют.
ИМХО, на текущий момент для среднего (это очень важное условие, т.е. нагрузки не экстремальные) бизнеса оптимально: общая SAN на 10Gbit, основные хранилища - DS35xx/DS37xx, резервные хранилища - серверы с программными iSCSI-таргетами.
Здесь "высокая доступность" действительно звучит как-то непонятно. Возможно, коллега очень уповает на возможности Remus'a.Dr. Grue писал(а): Но не обеспечу высокой доступности, а данный функционал, как я уже писал, нам необходим.
To Dr. Grue:
Потом коротенько отпишитесь, пожалуйста, тут, как Вам удаcтся добиться отсутствия любых перерывов в работе при отказах оборудования. А то поставщики HA-решений совсем другие бюджеты называют.
ИМХО, на текущий момент для среднего (это очень важное условие, т.е. нагрузки не экстремальные) бизнеса оптимально: общая SAN на 10Gbit, основные хранилища - DS35xx/DS37xx, резервные хранилища - серверы с программными iSCSI-таргетами.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Re: Конфигурация под 1c 8.2 УПП, MSSQL, терминал
Вот об этом я и пытаюсь сказать,gs писал(а):А вот сторадж лучше двухконтроллерный ИБМ с сервис-паком - его быстро починят, в отличие от инфортренда, на который фирменный сервис отсутствует как класс. Ну и свичи при этом будут без надобности - а это много тысяч долларов.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 14 гостей