|
Полное масштабирование 1С 8.х (клиент-серверный вариант) - кому удалось, идеи? ) | ☑ | ||
---|---|---|---|---|
0
sanfoto
16.12.12
✎
14:20
|
И так определимся с терминами масштабирования касательно 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 |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |