И так определимся с терминами масштабирования касательно 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-х)

Кто видел в реальности работу сего чуда техники?

(0) для данного форума слишком много букв, посему топик опять обратиться во флюд

Где такая трава растет? 1с в обозримом будущев в облака уйдет а не на НУМУ...

голосуем уважаемые))

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

(2) kauksi -
угу а "облака" это божественно чудо))
никак не связанное по производительности с аппаратной частью... )) - Ваш выбор скорее пункт 1) - так голосуйте

Сначало 1.

А потом, если наваляться, то

Ересь.

Некоторые вещи можно...

т.к есть уже реальные ПО работающее на системах с "Общей памятью" - например судя по всему "SAP HANA"...

(8) 17 релиз пробовал?

(9)  H A D G E H O G s

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

причем тут протокол работы с MS SQL и
сотни процессоров имеющие "Общую память" ?

(10) даа, не знаний.
Че, я вам все должен знать?

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

Уточняйте сразу.

"CPU1" <-"прямой доступ к локальной RAM1"->"Numa плата"<-"CPU2"->"прямой доступ к локальной RAM2".....

В реальности сложная многомерная топология... много материнок с как правило Двумя процессорами

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

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

Думайте шире))) Бросайте это дело...

тема сисек не раскрыта

(1) Согласен полностью )))

(14) ILM

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

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

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

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

Короче для мелких фирм - да не нужно.... Нам по любому необходимо... уже сейчас под сотню юзеров-онлайн.

+ сотрудников работа которых зависит от  Нашей "Информационной системы" -только в одном моем подразделении около 1,5 тыс.

(17) ты реально крут

(18) ты бог

(19) Нуф-Нуф

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

мне задали вопрос а НАФИГА МНЕ -масштабирование... я ответил))

Нуф-Нуф - как накурка отпусти прочитайте в (14) ILM

Добавь еще условия по надежности и быстродействию.

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

(24) Mikeware

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

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

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

так вот у нас пункт 2)

(17) Сказали вы батенька полную ахинею.

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

Извините не будем отклонятся от темы.

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

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

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

я все написал в сообщении (0) и далее буду отвечать только на касающееся (0)

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

Lean и учет по ТОС вам в руки (DBR и цепочку поставок)!!!
CRM+ выкиньте, маркетинг убейте. Сделайте вытягивающее производство и будет у вас счастье! А пока, приходите позже, через пару лет (или вперед по экстенсивному пути развитию вширь и вглубь).

(26). По яйцам то бить зачем? :)

(29) Сорри, наболело.
Когда закупают сервера и гоняют потом тысячи нормативов трудоемкости, когда делают миллионы планов, когда вводят сделку и меняют условия по ней постоянно, а потом по плановым калькуляциям считают цену и продают по ней, то хочется начать стрелять по коленкам или орать громко в ухо: "Цена от плановой калькуляции не зависит!"

Не слышат, бл...ть. Не смлышат!

(30)ILM

бывает)) и у нас тоже ))
но есть и "слышащие" ))

ладно, напоследок ссылки

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

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

3)Горизонтальное масштабирование
http://s017.radikal.ru/i429/1212/1d/e4f7fb245031.gif

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

притом процессоров естественно в пункте 2) можно применить очень много,

а начать всего с ДВУХ - и добавлять по мере необходимости .... до тысяч ядер в совокупности.

У меня только один вопрос. При таком объеме причем тут 1С?

Я понимаю что когда вы начинали с ларька, вам было достаточно легковой машины, чтобы товар развозить. Но если вы доросли до сети гипермаркетов, то глупо пытаться прикрутить тележку к легковой машине, чтобы развозить товар.

<<для такой системы однако есть придел - с некоторого «порогового» момента добавление ресурсов не даёт никакого полезного эффекта.>>
У 1С в целом есть пороговый момент, когда любое дальнейшее масштабирование не даст никакого полезного эффекта, все упрется в реалзацию трехзвенной архитектуры и гомнокод...

<<так вот у нас пункт 2)>>
Т.е. вы вертикально замасштабировали 1 сервер...
А что будете делать, когда ваш вертикальный сервер примет горизонталное положение и не включится?
Какой смысл вообще говорить о масштабировании без учета отказоустойчивости?

(0) Тема опять переастет во флуд, ибо автор не умеет описывать доступно свои мысли а также хромает аргументация, умение выстраивать логическую цепочку рассуждений. Нормальные мысли тонут в болоте сумбура. Это мое ИМХО разумеется.

Товарисчь в (14) просто не понял вопрос. Поэтому начал гнать полную пургу.
По пунктам :

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

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


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

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

Так же я не согласен с коллегами, которые выбрали п. 5

Программно можно решить далеко не все. Тем более касаемо 1С.

(38) Поржал над вашим бредом. Не удивлюсь если вы франь. Вы Теллур?  Они так же впаривать любят, без всяких гарантий и  ответственности)))
По ответу на пункт 3, делаю вывод  - оно нафиг не нужно.

(0) ужас. Сколько бессмысленного наукоподобного текста.
если вопрос правильно перефразировать то он звучит "лучше сервер 1С и скуэль на одном компе или на разных"

нет, надо же было так пальцы растопырить

(40) "Поржал над вашим бредом." - пропустим. Я не врач.

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

"По ответу на пункт 3, делаю вывод  - оно нафиг не нужно." Если у вас ситема работает при 3-х пользователях - далеко не факт, что она также отработает при 20-и. Вы предпочтете оставить хВирму без учета? Или будете предпринимать какие-то действия?
Внимание вопрос : какие?

(0) Бред какой-то :(

(41) Если я правильно понял вопрос - он звучит так :
1(один) сервер скуль и 1(один) сервер 1С уже не справляются. Что делать?

(44) не, не так. Именно что у чувака нет конкретной проблемы и нет конкретного случая.
Он просто хочет вывести теорему общего принципа масштабируемости любых систем 1С и заодно то ли похвастаться то ли порекламировать какую то хрень "NumaLink"

т.е. после дискусси он скажет во видите. Фигня вся эта горизонтально-вертикальная масштабируемость. Во нумалинк это сила

"распальцовка бывает горизонтальная...(машем показываем) вертикальная (машем, показываем).. и БЕСПОРЯДОЧНАЯ (машем кругами)"

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

то есть по сути прямые руки и знания должны  по идее решить большинство проблем.. не ?

(45) Если так - тады Ой.

(47) IamAlexy
>я слышал скуль нынче умный, можно файловыми группами адски
>рулить раскидывая данные таблиц чуть ли не по периодам в
>разные файловые группы..

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

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

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

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

При этом "1с виртуальная-объектная СУБД" - больше потребляет ресурсов CPU чем SQL/

>на уровне 3 (уровне баз данных) преобладают серверы с
вертикальным масштабированием.

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

http://www.bytemag.ru/articles/detail.php?ID=6670

(37) МуМу
>Тема опять переастет во флуд, ибо автор не умеет описывать
>доступно свои мысли..

Есть такое - ибо как ОПИСАТЬ в нескольких строчках
Объем информации во много тысяч строчек.... таки у меня не всегда получается))

+ это невозможно в принципе... ибо у каждого свой круг эрудиции и невозможно написать и для каждого
и + универсально)) - в небольшой статье.

(49)не буду спорить, я в этом плане туп

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

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

(53)  IamAlexy
1)
>но спрошу: а разве есть системы хранящие даные "объемно" ?

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

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

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

ИБО "1С запрос" - запрос по объектам, а не по "плоским" таблицам SQL/

У нас пока так, и мы еще не на самых мощных серверах сидим.
В планах пока двигаться только в этом направлении, пока не будет достигнут предел по вертикали :)

Вот еще один график... последователям горизонтального-много-серверного масштабирования посвящается ))

Рис. Сравнение Возможностей увеличения производительности.
http://s002.radikal.ru/i198/1212/6a/294e60f67474.gif