Microsoft Dynamics: «Сибирский цемент» приобрел Microsoft Dynamics AX для всех предприятий холдинга

[Blog bot]

Источник: http://microsoft.com/rus/dynamics/ab...2/_cement.mspx
==============



Источник: http://microsoft.com/rus/dynamics/ab...2/_cement.mspx

[jays]

Это ж надо ж так обосраться АНД Проджект: внедрили Аксу, а продажу лицензий - Корусу.

[Alex_K]

Э-э-э... И это ещё не всё. Первые лицензии тоже не АНД продавал, а новосибирский F1

[FE]

Видно, у Коруса совсем дела плохи, что пресс-релизы размещают о продаже лицензий...

[gl00mie]

...Поддерживать 7 отдельных инсталляций - это ж свихнуться можно Интересно, чья была идея? Неужели не нашлось возможности проложить каналы связи, чтобы работать удаленно в одной системе?

[driller]

Цитата:

Сообщение от gl00mie

...Поддерживать 7 отдельных инсталляций - это ж свихнуться можно Интересно, чья была идея? Неужели не нашлось возможности проложить каналы связи, чтобы работать удаленно в одной системе?

1. Да по каналам связи в Сибири не всё так гладко как в пределах МКАД-а, бывали случаи к примеру когда падал магистральный канал Ростелекома, и они не могли сказать, сколько времени потребуется на решение этой проблемы, и что тогда в этом случаи прикажете делать активу?
2. А есть уверенность в том что всё то что в единичных инсталляциях работает не слишком то и быстро, будет вообще способно работать в одной общей инсталляции.
А точнее сказать, у нас были большие проблемы с производительностью, выраженные в утечках памяти и падении AOS-а, которые решались через Microsoft. Можно конечно попробовать одним махом загнать всё в одну инсталляцию, но есть большой риск подскользнуться на этом пути, и пополнить компанию таких внедрений как Перекрёсток, Техносила и Милко, и попасть в объятья SAP, и вы уже прочтете другую новость «Вот ещё одна компания меняет DAX на SAP…»
Конечно в будущем есть планы, прийти к работе в единой системе, только делаться это думаю, будет очень осторожно.

[Ivanhoe]

Знаю проекты, где протянуть нормальную связь стоило дороже внедрения самой системы в несколько раз =)

[dmitryul]

driller, а спутниковый интернет не пробовали?

Сейчас связь вполне на уровне, например SpaceGate, реально где-то 150 кБайт/с (1 мБит/c).

Еще есть хороший вариант - терминальный доступ. Вполне успешно работали через обычный GSM модем.

Хотя, в принципе, все зависит от количества подключенных пользователей, в Вашем варианте (7 компаний холдинга), даже думать нечего - ставить 7 AOS'ов.

Хм, на моей памяти, редко сервер падает, максимум раз в полгода. А утечки памяти - виноват скорее SQL Server, он вообще любит все кешировать по-максимуму.

[Logger]

Цитата:

Сообщение от driller

А точнее сказать, у нас были большие проблемы с производительностью, выраженные в утечках памяти и падении AOS-а, которые решались через Microsoft. Можно конечно попробовать одним махом загнать всё в одну инсталляцию, но есть большой риск подскользнуться на этом пути, и пополнить компанию таких внедрений как Перекрёсток, Техносила и Милко, и попасть в объятья SAP, и вы уже прочтете другую новость «Вот ещё одна компания меняет DAX на SAP…»
Конечно в будущем есть планы, прийти к работе в единой системе, только делаться это думаю, будет очень осторожно.

Хм. Сколько же у них было конкурентных пользователей, что все так тяжело было ?

[driller]

Цитата:

Сообщение от dmitryul

driller, а спутниковый интернет не пробовали?

Сейчас связь вполне на уровне, например SpaceGate, реально где-то 150 кБайт/с (1 мБит/c).

Еще есть хороший вариант - терминальный доступ. Вполне успешно работали через обычный GSM модем.

Связью непосредственно не занимаюсь, передам это предложение ответственному за связь, он человек толковый. Думаю именно SpaceGate нам не подходит, судя по зоне обслуживание он восточную сибирь не покрывает. Но в любом случае спасибо за наводку!

Цитата:

Сообщение от dmitryul

Хм, на моей памяти, редко сервер падает, максимум раз в полгода. А утечки памяти - виноват скорее SQL Server, он вообще любит все кешировать по-максимуму.

У нас всё же был виноват сервер приложения, допускаю что и мы ещё где то кривым кодом помогали ему упасть.

Цитата:

Сообщение от Logger

Хм. Сколько же у них было конкурентных пользователей, что все так тяжело было ?

Давно это уже было, и непосредственно этой проблемой занимался мой бывший руководитель Lazy_Tiger, так что в каких-то деталях могу соврать, уж не обессудьте, за более конкретными разъяснениями можете обратиться к нему.
Проблема возникла сразу при переходе с 3-ки на 4-ку, там где AOS 3-ки тянул этих пользователей без проблем, 4-ка уже не справлялась.
Число конкурентных пользователей более 60-ти, AOS отъедал постепенно память и потом просто отваливался, могло это происходить ежечасно. Никаких ошибок в логе не оставлял, лишь клиентские ошибки такого вида «Object Server 01: RPC error: Client provided an invalid session ID 357».
Боролись с этой проблемой, запуская трассировку AOS-а, логи отсылали толи в Корус толи в Microsoft, они уже присылали заплатки, плюс к этому мы не правильно настроили AOS.
В AX Server Configuration Utility на закладке Database Tuning:
1. В поле Maximum open cursor: было указанно слишком большое значение 10000, уменьшили до 100.
2. В Maximum buffer size: указывали значение из расчёта в байтах, к примеру было записано так 40960, а нужно было писать из расчёта так чтобы это было 40 килобайт.

Базы у нас не большие порядка 55 гигабайт, на SQL Serer 2005 и 2008 х64, лежат на СХД, статистика обновляется, индексы перестраиваться, Tuning Advisor периодически используем. И не сказать, что всё порхает.

[Aleck]

Цитата:

Сообщение от gl00mie

...Поддерживать 7 отдельных инсталляций - это ж свихнуться можно Интересно, чья была идея? Неужели не нашлось возможности проложить каналы связи, чтобы работать удаленно в одной системе?

Чего такого сложного? Даже Ростелеком долго работал (если не до сих пор так живет) в отдельных системах по филиалам, и это притом что каналы для себя бесплатные

Да и 210 пользователей в AX да еще пр-ве - это надо очень много усилий вложить, чтобы производительность докрутить до приемлемого уровня.
А так всего 30 на сайт - норма для AX.

А проблемы с каналами бывают и очень близко к мск. То ледяной дождь электричество вырубит и склад неделю только на постоянно падающем gprs доступен, то фура кабель с оптикой заденет, но хозяйственный таджик что-нибудь лишнее выключит

И что в таком случае заводу/складу делать? Останавливать работу и ждать у моря погоды...

[fed]

Цитата:

Сообщение от Aleck

Да и 210 пользователей в AX да еще пр-ве - это надо очень много усилий вложить, чтобы производительность докрутить до приемлемого уровня.
А так всего 30 на сайт - норма для AX.

Это у тебя сведенья времен версии 3.0, а может даже 2.5. Счас (в 2009ой) в плане производительности в целом и в производственных рассчетов в частности, очень неплохо все продвинулось. Не далее как две недели назад гонял планирование с числом спецификаций - порядка 5000, вложеность - 9 уровней, число чистых потребностей 250000, результирующее количество созданных плановых ордеров - кажется 30 или 40 тысяч. Правда, надо сказать, ограничения по мощности рабочих центров убраны. Считалось 3 часа. Считалось на двух банальных виртуализированных батч-серверах по 4 ядра и 6 гигов на каждом. На тех же двух серверах, те же производственные спецификации полностью обсчитываются за час примерно.

Я думаю месяца через 2-3 этот проект дойдет до планирования с ограничением мощности, самому интересно - сколько такой план планироваться будет. Я подозреваю - порядка 5-6 часов (но это только предчуствие )

[Aleck]

Цитата:

Сообщение от fed

Это у тебя сведенья времен версии 3.0, а может даже 2.5. Счас (в 2009ой) в плане производительности в целом и в производственных рассчетов в частности, очень неплохо все продвинулось. Не далее как две недели назад гонял планирование с числом спецификаций - порядка 5000, вложеность - 9 уровней, число чистых потребностей 250000, результирующее количество созданных плановых ордеров - кажется 30 или 40 тысяч. Правда, надо сказать, ограничения по мощности рабочих центров убраны. Считалось 3 часа. Считалось на двух банальных виртуализированных батч-серверах по 4 ядра и 6 гигов на каждом. На тех же двух серверах, те же производственные спецификации полностью обсчитываются за час примерно.

Я думаю месяца через 2-3 этот проект дойдет до планирования с ограничением мощности, самому интересно - сколько такой план планироваться будет. Я подозреваю - порядка 5-6 часов (но это только предчуствие )

Эээ... ну хорошо Аксапте, если продвинулось...
5000 спецификаций это на всех 9 уровнях или на верхнем уровне?

[fed]

Цитата:

Сообщение от Aleck

Эээ... ну хорошо Аксапте, если продвинулось...
5000 спецификаций это на всех 9 уровнях или на верхнем уровне?

На всех. Правда у них у каждой по много версий.

[gl00mie]

Цитата:

Сообщение от driller

Да по каналам связи в Сибири не всё так гладко как в пределах МКАД-а

Я лично вовсе не имел в виду пределы МКАДа - есть примеры, когда люди далеко за его пределами (на Урале, например) нормально работают удаленно в системе, развернутой в Москве.

Цитата:

Сообщение от driller

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

Как альтернатива Ростелекому с его ржавой медью есть еще Транстелеком с его оптоволокном есть, как уже упоминали, сотовые операторы с GPRS'ом, есть спутниковый тырнет... Резервные каналы никто не отменял.

Цитата:

Сообщение от driller

и что тогда в этом случаи прикажете делать активу?

Это форс-мажор, от такого никакое внедрение не застраховано. К примеру, я работал одно время в компании, которая несколько дней фактически простояла из-за пожара на электростанции и последующего обесточивания нескольких кварталов. А казалось бы, почти центр Москвы, вся инфраструктура под боком, все нормально было... Почитайте Черного лебедя того же.

Цитата:

Сообщение от driller

у нас были большие проблемы с производительностью, выраженные в утечках памяти и падении AOS-а, которые решались через Microsoft.

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

Цитата:

Сообщение от Ivanhoe

Знаю проекты, где протянуть нормальную связь стоило дороже внедрения самой системы в несколько раз =)

И что это доказывает?..

Цитата:

Сообщение от dmitryul

Еще есть хороший вариант - терминальный доступ. Вполне успешно работали через обычный GSM модем.

Для 4.0/2009 с их требованиями к каналу, я бы сказал, это единственный вариант.

Цитата:

Сообщение от Aleck

Чего такого сложного?

Из моего скромного опыта, сложно поддерживать постоянно разъезжающиеся приложения либо обновлять приложения сразу везде, даже если не на всех сайтах нужны новые модификации. 7 приложений не поддерживал, врать не буду, - с меня хватило двух...

Цитата:

Сообщение от Aleck

Даже Ростелеком долго работал (если не до сих пор так живет) в отдельных системах по филиалам, и это притом что каналы для себя бесплатные

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

Цитата:

Сообщение от Aleck

Да и 210 пользователей в AX да еще пр-ве - это надо очень много усилий вложить, чтобы производительность докрутить до приемлемого уровня.

А по-моему, такие усилия окупаются, тем более что именно с производством будут работать отнюдь не все эти две сотни пользователей.

Цитата:

Сообщение от Aleck

А проблемы с каналами бывают и очень близко к мск. То ледяной дождь электричество вырубит и склад неделю только на постоянно падающем gprs доступен, то фура кабель с оптикой заденет, но хозяйственный таджик что-нибудь лишнее выключит

И что, давайте каждому поставим по однопользовательской 1С-ке, работающей в файловом режиме? Или будем вести все в амбарных книгах и считать на счетах?

Цитата:

Сообщение от Aleck

И что в таком случае заводу/складу делать? Останавливать работу и ждать у моря погоды...

Вы, похоже, работаете с SAP'ом, если судить по соседним обсуждениям (хотя, может, это просто мне так показалось) - скажите, все перечисленные проблемы специфичны только для централизованных внедрений Аксапты? В других системах используют погодонезависимые и таджикоустойчивые технологии инопланетян? Поведайте, какие именно, может, их и для Аксапты можно приспособить...

[Aleck]

Цитата:

Сообщение от fed

На всех. Правда у них у каждой по много версий.

Т.е. получатеся 1 процессорное ядро с 1,5 гб. справлялось с задачей развертывания 1 многоуровневый BOM в среднем с 500 позициями за 5,76 секунд?

А чего с СУБД происходило в этот момент меряли?

[Ivanhoe]

Цитата:

Сообщение от gl00mie

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

Цитата:

Сообщение от Ivanhoe

Знаю проекты, где протянуть нормальную связь стоило дороже внедрения самой системы в несколько раз =)

Цитата:

Сообщение от gl00mie

И что это доказывает?..

Это ничего не доказывает. Это один из возможных ответов на вопрос "неужели...?".

[Aleck]

Цитата:

Сообщение от gl00mie

И что, давайте каждому поставим по однопользовательской 1С-ке, работающей в файловом режиме? Или будем вести все в амбарных книгах и считать на счетах?

Зачем же так утрировать? Проблемы с каналами на нашей необъятной родине много где есть, есть отдельные районы, где только медленный спутник с большими задержками и большим процентом потерянных пакетов...
Их бывает не решить за разумный бюджет. Не свою же спутник всем запускать на нужную орбиту или оптику за несколько тысяч км по тундре тянуть

Цитата:

Сообщение от gl00mie

Вы, похоже, работаете с SAP'ом, если судить по соседним обсуждениям (хотя, может, это просто мне так показалось) - скажите, все перечисленные проблемы специфичны только для централизованных внедрений Аксапты? В других системах используют погодонезависимые и таджикоустойчивые технологии инопланетян? Поведайте, какие именно, может, их и для Аксапты можно приспособить...

Сейчас с Сапом, с Аксаптой в два раза больше работал
Если говорить про SAP, то в случае необходимости (совсем плохо с каналами связи) удаленная инсталляция работает без проблем. При этом стандартными средствами системы и без программирования поддерживаются:
1. Обмен всеми необходимыми документами и НСИ.
2. Гарантированная доставка сообщений по плохим каналам с подтверждениями и доп. запросами, в случае сбоев. Это кстати можно приспособить и для Аксапты
3. Совсем страшная штука, как прозрачные для пользователя онлайн-запросы в другую систему. Пользователь нажимает на ссылку на документ, которого нет в системе в которую он залогинен - документ лежит в другой системе. Так эта страшная система делает запрос в удаленную и показывает его пользователю, если есть права. Но такое обычно у очень крупных клиентов мультиков используется.
Это если вкратце... К примеру, отдельная инсталляция на большом удаленном скаде/РЦ часто делается и всё работает как часы без программизма.

[fed]

Цитата:

Сообщение от Aleck

Т.е. получатеся 1 процессорное ядро с 1,5 гб. справлялось с задачей развертывания 1 многоуровневый BOM в среднем с 500 позициями за 5,76 секунд?

А чего с СУБД происходило в этот момент меряли?

СУБД особо не напрягается в такие моменты. Там просто куча однотипных тупых запросов по выбору из одной таблицы одной записи по ключу шло. Во вторых, я не очень понял, откуда ты 500 позиций взял. Да, там было штук 30-40 конечных продуктов, в которых и вправду штук 200-300-400 позиций было. Но все сборочные узлы конечно же меньше строк имели. Ну и вообще-то, сводное разворачивает многоуровневый BOM как одно целое, только если там в строках фантомные спецификации. Что, вообще говоря, не слишком часто используется. А так - сводное тупо по уровням идет, а развернуть и спланировать спецификацию строк из 20-30 - очень больших ресурсов не надо.
Да - и для протокола: Я пристально за памятью на AOS не следил, но по моему, там размер процесса ни разу 2.5 гигов не превосходил. Так что может попробуем память подрезать со временем.

[Raven Melancholic]

Цитата:

Сообщение от fed

Эрезультирующее количество созданных плановых ордеров - кажется 30 или 40 тысяч.

Ого. Я что с этими 3 десятками тысяч спланированных заказов пользователи делали? Я что-то не представляю аналитика, который может оперировать таким объемом информации.