Виталий
@deleburth
CTO в ЕАЕ-Консалт
Information
- Rating
- Does not participate
- Location
- Москва, Москва и Московская обл., Россия
- Date of birth
- Registered
- Activity
Specialization
Sales Director, Chief information officer (CIO)
Lead
В вашем случае такое решение с десктопных железом подходило, значит оно было самым обоснованным и верным решением. Всё ведь зависит от требований заказчика: надёжность, производительность, стоимость владения и т.д.
И облака - это далеко не единственно верное решение, зачастую подойдёт и что-то попроще у себя в серверной или, наоборот, целый железный кластер в коммерческом ЦОДе. Просто облака для 1С незаслуженно игнорируют, вот и появился повод написать об этом
И тут спасибо за замечание, дополнил статью.
Использовали данную версию платформы, так как конфигурация, которую мы используем для функционального тестирования, сейчас работает на этой версии платформы и обновление только запланировано
.
Спасибо за замечание, дополнил статью. Тестировались не одинаковые железяки, а стандартные предложения облачных ресурсов.
В случае с облаками сложно тестировать одинаковое железо на одинаковых гипервизорах, потому что у каждого вендора свои подходы к оборудованию и гипервизорам. У MTS - это OpenStack, у Cloud - вендорский OpenStack, у Яндекса - собственная разработка на базе KVM. Причём у Yandex Cloud и Cloud их облако - это ПАК, программно-аппаратный комплекс, где есть чёткие ограничения по используемому железу и ПО.
Не было цели показать нерепрезентативность теста, наоборот, он как раз точно выполняет свою задачу. Суть в том, что облака разные, у них разный фундамент и из-за этого разные результаты.
Тестировали стандартные предложения облаков:
МТС дали в базе 3Ггц, Yandex Cloud - 2 Ггц, Cloud - 2,6 ГГц, VK - 2,3ГГц, Selectel 2,4 Ггц.
Будет повод осенью сделать расширенный перетест. У нас как раз сейчас в тестировании дополнительные хостинг-провайдеры, у яндекса dslqn из превью новое железо, а у Selectel возьмём машины 3Ггц.
Если сравнивать в лоб выделенный сервер и облако, то по производительности выделенный сервер, естественно, победит. На нём можно сделать больше тюнинга производительности железа, в отличие от полного отсутствия тюнинга в облаке. А мы говорим именно об облаке, а не виртуализации, которую можно организовать самостоятельно.
Но в нашей практике мы работаем с клиентами - непрерывными производствами, которым важно обеспечить SLA 99,9 и выше и при этом они считают деньги и для них новая инсталляция 1С сопряжена с инвестициями в новое железо.
Если в облаке достаточно арендовать 2 ВМ для размещения кластера 1С, то в собственном ЦОД это уже 2 физических сервера для обеспечения отказоустойчивости + 1 сервер hot stand-by, а это уже значительно большие затраты, чем купить один сервер и сравнивать облако с ним.
Про PG - соглашусь, это действительно так. Во всех облаках проводились одинаковые настройки PG SQL, за исключением PaaS сервисов Yandex и Selectel, там мы были ограничены настройками, которые позволяет делать платформа.
У нас на текущий момент размещены инсталляции 1C, как в облаках Cloud и Yandex Cloud, так и на оборудовании заказчиков. Цель статьи показать, что облака применимы для размещения 1С, показать наш опыт и развеять некоторые страхи и заблуждения заказчиков, связанные с облаками. Из продвижения - только ссылка.
Это возможно, но смысл платформы DSS именно в том, чтобы помочь принимать решения, объединяя данные из различных системы в одну платформу через API, а решать частные задачи каждого бизнеса будут модули от других, специализированных, вендоров.
Уже есть отличные специализированные решения для АСУТП, MES, кадрового, складского, бухгалтерского учёта и т.д. В случае создания такой платформы принятия решений, нет необходимости внедрять ERP систему, заменяя каждый из уже имеющихся продуктов в компании. Можно подключить уже работающие системы по API. А это значительная экономия денег и времени, по сравнению со внедрением классической ERP-системы.
Да, это верное определение - Система принятия решений
Действительно, всё на yandex cloud сложить нельзя, ответственность за персональные данные - это всегда ответственность предприятия - оператора ПДн. Так как yandex cloud прошёл аттестацию по ФЗ-152 это лишь снизило наши затраты на дополнительную работу по аттестации ИСПДн и обеспечению безопасности.
Штрафы пока что смешные, а когда они станут оборотными - будет уже интереснее. Но в нашей стране суровость законов компенсируется избирательностью их применения. На это, конечно, нельзя рассчитывать как на правило, поэтому ИСПДн надо защищать и аттестовывать.
Yandex Cloud действительно не сертифицирован для размещения SAP HANA. Но мы, как ЕАЕ-Консалт, прошли сертификацию, позволяющую размещать и обслуживать системы SAP в Yandex Cloud, но только в том случае, если инфраструктура и basis обслуживаются нашими специалистами.
По анализу стоимости, если интересно, напишите мне в личку, пожалуйста
Мы отказались по нескольким причинам:
Поддержка 22% на 150 человек это не дорого. Но мы покупали SAP на 8000 человек, а когда ужались до 150, то поддержку нужно было платить, как за все 8000 человек.
Мы рассматривали переход на собственный Z-код, но с учётом масштаба компании, нам было выгоднее сменить систему на 1С и не тратить ресурсы на постоянную доработку SAP, а получать все обновления, связанные с законодательством от вендора 1С.
Да, всё верно. SAP - это дорого, долго, как и любая другая ERP, в том числе 1С:ERP. Но как только масштаб бизнеса переходит определённый порог, например, становится международным или требуется задействовать специфические решения, такие как сквозной процесс для нефтегаза, начиная от геологоразведки и бурения, и заканчивая продажами и логистикой продукции до конечного потребителя, а ещё и в совместном предприятии, то готовые решения есть только у SAP и купить и внедрить его будет дешевле, чем внедрить что-то другое.
Но это специфика, понятно что SAP не везде целесообразен, по этой причине мы и перешли на 1С - это было дешевле для нас, так как исчезли специфические потребности бизнеса
Спасибо, про версию директум уточнил у коллеги, он подтвердил, что опечатались, версия должна быть 3.6
А по миграции с MS SQL на Postgre SQL мы были одними из первых. Не первые, кто внедрил Directum RX на PostgreSQL, потому что это задача не очень сложная, но точно одни из первых, кто мигрировал с MS SQL. Мы этот проект вели в мучениях с вендором и на основе нашего опыта и обнаруженных проблем дорабатывался инструмент вендора для конвертации данных.
Спасибо за замечание, тоже исправил!
Спасибо! Всё скорректировал к единой нотации
В тот вечер я мечтал о кнопке удалённого выключения… Спасибо, что хоть в инструкциях были консольные команды, как правильно отключить работу datamover, чтобы он перестал обрабатывать данные, это сильно успокоило мои нервы. Да и вообще за 4 года работы с EMC у меня сложилось довольно негативное отношение к продуктам этой компании (Используем SMB и mid-line СХД), в частности из-за техподдержки и спонтанных багов в работе оборудования, исправления которых приходиться ждать по 2-3 квартала.
Хотя бывают и случаи сопротивления оборудования.