Имя: Пароль:
1C
1С v8
Полное масштабирование 1С 8.х (клиент-серверный вариант) - кому удалось, идеи? )
, ,
0 sanfoto
 
16.12.12
14:20
1. "Верт.масштаб."+делим функционалНаМного БД и серв. 25% (2)
2. "Полное масштабирование" - возможно Аппаратно 25% (2)
3. Все можно решить программно. 25% (2)
4. Лучше использовать-"Горизонтальное масштабирование 13% (1)
5. я ваще не в теме ... в описании много БуКав.. 13% (1)
Всего мнений: 8

И так определимся с терминами масштабирования касательно 1С 8.х:
-------------------------------------------------------------------
1)"Горизонтальное масштабирование" -

вариант наращивания количества серверов соединяемых коммуникационной сетью - как правило Ethernet имеющую "Высокую Латентность" - т.е. как результат низкую пропускную способность при малых пакетах.
(пример Gigabit Ethernet дает 30 Мегабайт/сек при работе с пакетами 4 Кбайт - дефолтными для MS SQL)
В итоге:
а)Имеем довольно низкую производительность изначально - даже при одном пользователе в программе.
б)Но имеем некоторый стабильный коэф-производительности при росте количества пользователей
в)для такой системы однако есть придел - с некоторого «порогового» момента добавление ресурсов не даёт никакого полезного эффекта.

-----------------------------------------------------------
2) "Вертикальное масштабирование"

- Увеличение производительности каждого компонента системы c целью повышения общей производительности.

В случае со связкой "Сервер 1С"<-->"SQL".
а)Убираем из связки Сетевые интерфейсы (т.е. все на одном сервере).
б)На сервере ставим процессоры с наиболее возможной частотой ядер.
в)позаботимся о скоростной дисковой системе - например SSD
г)естественно позаботимся о значительном объеме оперативной памяти
В итоге:
- имеем максимальную производительность изначально на пользователя (как правило в 3-4 раза выше чем при "Горизонтальном масштабировании"
- но при определенном количестве Активных пользователей - однозначно начнется падение коэф-производительности.
- на текущий момент рост частот процессоров - уперся в физические ограничения материалов чипов и невозможность из-за большого тепло-выделения - роста количества Высокочастотных ядер в одном чипе => есть придел и у такого вида масштабирования.

------------------------------------------
3) "Полное масштабирование" -

Система называется масштабируемой, если она способна увеличивать производительность пропорционально дополнительным ресурсам.

Тут у меня на текущий момент только одна идея - использовать системы с "Общей памятью" и "Общими процессорами" - работающими под управлением "Единой операционной системы".

Для примера есть коммуникационные платы интер-коннекта "NumaLink" - на серверах SGI/ Кстати поддерживают и операционную систему Windows / - появляется возможность использования ТЫСЯЧ многочастотных ядер - и все видны Единой операционной системе и приложениям внутри её.
(В России эти сервера в основном на устаревших "NumaLink4 c процами Itanium2" - но у буржуев таки есть уже и на Xeona-х)

Кто видел в реальности работу сего чуда техники?
1 shuhard
 
16.12.12
14:33
(0) для данного форума слишком много букв, посему топик опять обратиться во флюд
2 kauksi
 
16.12.12
14:33
Где такая трава растет? 1с в обозримом будущев в облака уйдет а не на НУМУ...
3 sanfoto
 
16.12.12
14:39
голосуем уважаемые))

(1) shuhard - так я понял вы выбрали "4. я ваще не в теме ... в описании много БуКав.." вот и нажмите))

(2) kauksi -
угу а "облака" это божественно чудо))
никак не связанное по производительности с аппаратной частью... )) - Ваш выбор скорее пункт 1) - так голосуйте
4 H A D G E H O G s
 
16.12.12
14:40
Сначало 1.

Лучше использовать-"Горизонтальное масштабирование
5 H A D G E H O G s
 
16.12.12
14:40
А потом, если наваляться, то

"Верт.масштаб."+делим функционалНаМного БД и серв.
6 H A D G E H O G s
 
16.12.12
14:40
Ересь.

"Полное масштабирование" - возможно Аппаратно
7 H A D G E H O G s
 
16.12.12
14:41
Некоторые вещи можно...

Все можно решить программно.
8 sanfoto
 
16.12.12
14:41
т.к есть уже реальные ПО работающее на системах с "Общей памятью" - например судя по всему "SAP HANA"...

"Полное масштабирование" - возможно Аппаратно
9 H A D G E H O G s
 
16.12.12
14:43
(8) 17 релиз пробовал?
10 sanfoto
 
16.12.12
14:46
(9)  H A D G E H O G s

я поражаюсь вы "инженер знаний" или "инженер НЕ-знаний"? ))

причем тут протокол работы с MS SQL и
сотни процессоров имеющие "Общую память" ?
12 H A D G E H O G s
 
16.12.12
14:51
(10) даа, не знаний.
Че, я вам все должен знать?

Shared Memory - общая память.

Уточняйте сразу.
13 sanfoto
 
16.12.12
14:53
"CPU1" <-"прямой доступ к локальной RAM1"->"Numa плата"<-"CPU2"->"прямой доступ к локальной RAM2".....

В реальности сложная многомерная топология... много материнок с как правило Двумя процессорами
14 ILM
 
гуру
16.12.12
14:56
1) Нафиг масштабировать?
2) Удовлетворять хотелки локальных пользователей и увеличивать объемы данных в десятки сотни раз? Зачем?
3)Как это помогает компаниям зарабатывать деньги?
4) А в деньгах можете гарантировать эффективность масштабирования, срок окупаемости? Нет? Жаль...

Ваше масштабирование просто лишняя трата денег для компании. Что вы им обещаете: надёжность, быстроту, доступность.

Думайте шире))) Бросайте это дело...
15 Нуф-Нуф
 
16.12.12
14:57
тема сисек не раскрыта
16 ILM
 
гуру
16.12.12
14:57
(1) Согласен полностью )))
17 sanfoto
 
16.12.12
15:12
(14) ILM

ну таки Мое подразделение часть крупного холдинга,
подразделение занимается -"производством пищевых продуктов".

В производстве очень много "уровней переделов" продукции.
На данный момент достраивается еще один большой завод..

Короче нужно "Оперативно планировать" как выпуск продукции так и где что и когда будет делать и на каком оборудовании, так и планировать закуп сырья, так и анализ продаж (+CRM), так и "Выгодность))", так и ЛОГИСТИКА... так и вообще все это должно связано ВОЕДИНО.

А пищевые продукты еще имеют и небольшой срок годности..

Короче для мелких фирм - да не нужно.... Нам по любому необходимо... уже сейчас под сотню юзеров-онлайн.
18 sanfoto
 
16.12.12
15:19
+ сотрудников работа которых зависит от  Нашей "Информационной системы" -только в одном моем подразделении около 1,5 тыс.
19 Нуф-Нуф
 
16.12.12
15:20
(17) ты реально крут
20 Нуф-Нуф
 
16.12.12
15:20
(18) ты бог
21 sanfoto
 
16.12.12
15:22
(19) Нуф-Нуф

уважаемый что курите на выходных? ))

мне задали вопрос а НАФИГА МНЕ -масштабирование... я ответил))
22 sanfoto
 
16.12.12
15:24
Нуф-Нуф - как накурка отпусти прочитайте в (14) ILM
23 Мимохожий Однако
 
16.12.12
15:24
Добавь еще условия по надежности и быстродействию.

я ваще не в теме ... в описании много БуКав..
24 Mikeware
 
16.12.12
15:32
(17) а что, "сотня юзеров" - это нереально много?
25 sanfoto
 
16.12.12
15:39
(24) Mikeware

>а что, "сотня юзеров" - это нереально много?

1)нет,
не так уж и много если они все тупо зашли в 1с, а потом запустили программу "Пасьянс".))

2)да много,
 если они все работают НЕПРЕРЫВНО ОН-ЛАЙН (+некоторые на моноблоках, некоторые на ТСД)- притом в довольно громоздкой конфигурации УПП + куча фоновых заданий(синхронизации с холдингом... с различными системами заказов и т.п. и т.д.)

так вот у нас пункт 2)
26 ILM
 
гуру
16.12.12
15:41
(17) Сказали вы батенька полную ахинею.

Ответьте честно на весь форум:
1) 100 процентное выполнение плана - в каком количестве случаев?
2) Отклонение фактического выпуска продукции от нормативного в районе +- 3% - какова вероятность?
3) На скольких переделах у вас отсутствует фактор людей и нет отклонений в персонале?
27 sanfoto
 
16.12.12
15:50
Извините не будем отклонятся от темы.

"Полное масштабирование 1С 8.х (клиент-серверный вариант) - кому удалось, идеи? )"

ГОЛОСУЕМ и пишем ПО ТЕМЕ,
а не обсуждаем что и как там конкретно на моей работе.

короче хорош - мну тролить))

я все написал в сообщении (0) и далее буду отвечать только на касающееся (0)
28 ILM
 
гуру
16.12.12
15:50
(26) Если у вас:
1 - Меньше 100% (зачем планировать?)
2 - Меньше 100% (зачем так точно нормировать?)
3 - Больше 0 (тогда у вас есть изменчивость процесса и ваша информационная система является учетной, а не управляющей).

Lean и учет по ТОС вам в руки (DBR и цепочку поставок)!!!
CRM+ выкиньте, маркетинг убейте. Сделайте вытягивающее производство и будет у вас счастье! А пока, приходите позже, через пару лет (или вперед по экстенсивному пути развитию вширь и вглубь).
29 DEVIce
 
16.12.12
15:59
(26). По яйцам то бить зачем? :)
30 ILM
 
гуру
16.12.12
16:05
(29) Сорри, наболело.
Когда закупают сервера и гоняют потом тысячи нормативов трудоемкости, когда делают миллионы планов, когда вводят сделку и меняют условия по ней постоянно, а потом по плановым калькуляциям считают цену и продают по ней, то хочется начать стрелять по коленкам или орать громко в ухо: "Цена от плановой калькуляции не зависит!"

Не слышат, бл...ть. Не смлышат!
31 sanfoto
 
16.12.12
16:18
(30)ILM

бывает)) и у нас тоже ))
но есть и "слышащие" ))
32 sanfoto
 
16.12.12
16:53
ладно, напоследок ссылки

1) Масштабируемость
wiki:Масштабируемость

2)Вертикальное масштабирование
http://s020.radikal.ru/i701/1212/2c/79e1b2e2f985.gif

3)Горизонтальное масштабирование
http://s017.radikal.ru/i429/1212/1d/e4f7fb245031.gif
33 sanfoto
 
16.12.12
16:55
2) пордон это Полное масштабирование))
http://s020.radikal.ru/i701/1212/2c/79e1b2e2f985.gif
34 sanfoto
 
16.12.12
16:58
притом процессоров естественно в пункте 2) можно применить очень много,

а начать всего с ДВУХ - и добавлять по мере необходимости .... до тысяч ядер в совокупности.
35 Aleksey
 
16.12.12
17:02
У меня только один вопрос. При таком объеме причем тут 1С?

Я понимаю что когда вы начинали с ларька, вам было достаточно легковой машины, чтобы товар развозить. Но если вы доросли до сети гипермаркетов, то глупо пытаться прикрутить тележку к легковой машине, чтобы развозить товар.
36 zva
 
16.12.12
19:28
<<для такой системы однако есть придел - с некоторого «порогового» момента добавление ресурсов не даёт никакого полезного эффекта.>>
У 1С в целом есть пороговый момент, когда любое дальнейшее масштабирование не даст никакого полезного эффекта, все упрется в реалзацию трехзвенной архитектуры и гомнокод...

<<так вот у нас пункт 2)>>
Т.е. вы вертикально замасштабировали 1 сервер...
А что будете делать, когда ваш вертикальный сервер примет горизонталное положение и не включится?
Какой смысл вообще говорить о масштабировании без учета отказоустойчивости?
37 МуМу
 
16.12.12
19:36
(0) Тема опять переастет во флуд, ибо автор не умеет описывать доступно свои мысли а также хромает аргументация, умение выстраивать логическую цепочку рассуждений. Нормальные мысли тонут в болоте сумбура. Это мое ИМХО разумеется.

Все можно решить программно.
38 Ork
 
16.12.12
20:08
Товарисчь в (14) просто не понял вопрос. Поэтому начал гнать полную пургу.
По пунктам :

"1) Нафиг масштабировать?"
Для того, чтобы добавляя в систему пользователей не делить с ними уже существующие ресурсы (как аппаратные - добавить рабочих мест) так и временые (не увеличивать задержки записи/чтения пропорционально добавленному количеству рабочих мест).

"2) Удовлетворять хотелки локальных пользователей и увеличивать объемы данных в десятки сотни раз? Зачем?"
В простейшем случае масштабирование не направлено на "Удовлетворять хотелки локальных пользователей".


"3)Как это помогает компаниям зарабатывать деньги?"
Точно так же как и система без масштабирования.

"4) А в деньгах можете гарантировать эффективность масштабирования, срок окупаемости? Нет? Жаль..."
Подход такой же как и вообще внедрение учетной системы/системы планирования.
39 Ork
 
16.12.12
20:12
Так же я не согласен с коллегами, которые выбрали п. 5

Программно можно решить далеко не все. Тем более касаемо 1С.
40 ILM
 
гуру
16.12.12
20:45
(38) Поржал над вашим бредом. Не удивлюсь если вы франь. Вы Теллур?  Они так же впаривать любят, без всяких гарантий и  ответственности)))
По ответу на пункт 3, делаю вывод  - оно нафиг не нужно.
41 i-rek
 
16.12.12
20:53
(0) ужас. Сколько бессмысленного наукоподобного текста.
если вопрос правильно перефразировать то он звучит "лучше сервер 1С и скуэль на одном компе или на разных"

нет, надо же было так пальцы растопырить
42 Ork
 
16.12.12
20:54
(40) "Поржал над вашим бредом." - пропустим. Я не врач.

"Вы Теллур?" - нисколько.

"По ответу на пункт 3, делаю вывод  - оно нафиг не нужно." Если у вас ситема работает при 3-х пользователях - далеко не факт, что она также отработает при 20-и. Вы предпочтете оставить хВирму без учета? Или будете предпринимать какие-то действия?
Внимание вопрос : какие?
43 Джинн
 
16.12.12
20:55
(0) Бред какой-то :(
44 Ork
 
16.12.12
20:56
(41) Если я правильно понял вопрос - он звучит так :
1(один) сервер скуль и 1(один) сервер 1С уже не справляются. Что делать?
45 i-rek
 
16.12.12
20:58
(44) не, не так. Именно что у чувака нет конкретной проблемы и нет конкретного случая.
Он просто хочет вывести теорему общего принципа масштабируемости любых систем 1С и заодно то ли похвастаться то ли порекламировать какую то хрень "NumaLink"
46 i-rek
 
16.12.12
21:00
т.е. после дискусси он скажет во видите. Фигня вся эта горизонтально-вертикальная масштабируемость. Во нумалинк это сила

"распальцовка бывает горизонтальная...(машем показываем) вертикальная (машем, показываем).. и БЕСПОРЯДОЧНАЯ (машем кругами)"
47 IamAlexy
 
16.12.12
21:04
я слышал скуль нынче умный, можно файловыми группами адски рулить раскидывая данные таблиц чуть ли не по периодам в разные файловые группы..

то есть по сути прямые руки и знания должны  по идее решить большинство проблем.. не ?
48 Ork
 
16.12.12
21:05
(45) Если так - тады Ой.
49 sanfoto
 
17.12.12
06:12
(47) IamAlexy
>я слышал скуль нынче умный, можно файловыми группами адски
>рулить раскидывая данные таблиц чуть ли не по периодам в
>разные файловые группы..

Вы не понимаете сути проблемы... затык не в SQL,

а в том что "1с-многомерные Объекты -постоянно раскладываются в Реляционный(табличный) плоский вид, и обратные операции... притом сама работа (бизнес логика) происходит с "Собранными объектами" "

По сути имеем связь
"SQL-реляционная СУБД"<-->"1с виртуальная-объектная СУБД"

так вот естественно нужна быстрая связь между ними - и достаточно скоростных ядер CPU/ и др. ресурсов.

При этом "1с виртуальная-объектная СУБД" - больше потребляет ресурсов CPU чем SQL/
50 sanfoto
 
17.12.12
06:15
>на уровне 3 (уровне баз данных) преобладают серверы с
вертикальным масштабированием.

>Уровень 2 (уровень приложений) становится областью, где
>сосуществуют вертикальная и горизонтальная архитектуры.

http://www.bytemag.ru/articles/detail.php?ID=6670
51 sanfoto
 
17.12.12
06:21
(37) МуМу
>Тема опять переастет во флуд, ибо автор не умеет описывать
>доступно свои мысли..

Есть такое - ибо как ОПИСАТЬ в нескольких строчках
Объем информации во много тысяч строчек.... таки у меня не всегда получается))
52 sanfoto
 
17.12.12
06:25
+ это невозможно в принципе... ибо у каждого свой круг эрудиции и невозможно написать и для каждого
и + универсально)) - в небольшой статье.
53 IamAlexy
 
17.12.12
07:04
(49)не буду спорить, я в этом плане туп

но спрошу: а разве есть системы хранящие даные "объемно" ?
все же в любом случае в плоские таблицы разворачивают любые "объемные объекты"..

соответственно задача сводится к элементарной - той с которой мы работает постоянно: обеспечение быстродействия и оптимальности выборок..
54 sanfoto
 
17.12.12
07:13
(53)  IamAlexy
1)
>но спрошу: а разве есть системы хранящие даные "объемно" ?

да - есть такие системы.

2)
>соответственно задача сводится к элементарной - той с которой
>мы работает постоянно: обеспечение быстродействия и
>оптимальности выборок..

тут тоже не все просто...
"1с запрос" <НЕ РАВЕН> "SQL запрос" -

ИБО "1С запрос" - запрос по объектам, а не по "плоским" таблицам SQL/
55 Повелитель
 
17.12.12
07:27
У нас пока так, и мы еще не на самых мощных серверах сидим.
В планах пока двигаться только в этом направлении, пока не будет достигнут предел по вертикали :)

"Верт.масштаб."+делим функционалНаМного БД и серв.
56 sanfoto
 
17.12.12
10:31
Вот еще один график... последователям горизонтального-много-серверного масштабирования посвящается ))

Рис. Сравнение Возможностей увеличения производительности.
http://s002.radikal.ru/i198/1212/6a/294e60f67474.gif
Требовать и эффективности, и гибкости от одной и той же программы — все равно, что искать очаровательную и скромную жену... по-видимому, нам следует остановиться на чем-то одном из двух. Фредерик Брукс-младший