Комментарии 41
MS SQL Server и PostgresPro. При этом PostgresPro является более оптимальным решением на сегодняшний день с точки зрения скорости работы, функционала и стоимости обслуживания.
Как интересно. Лично я бы с удовольствием почитал про большую оптимальность функционала (!) Postgres в разрезе 1С, равно как и посмотрел на расчет стоимости обслуживания.
Уточнение, речь идёт о PostgresPro, а не о чистом PostgreSQL. PostgresPro — это уже оптимизированная версия для работы с 1С, которая включает патчи для повышения производительности и стабильности при работе с 1С. Дополнительно к этому есть техническая поддержка продукта и возможность без проблем приобрести ПО, с MS SQL сейчас сложно в этом плане из-за санкций. Если у вас уже есть лицензии или нужно поднять типовую конфигурацию без доработок до 100 человек, то да - "из коробки" MS SQL будет лучше по производительности и простоте внедрения\обслуживания.
а зачем все вязать к одному серверу и через инет - сделайте локальные кассы и торгуйте независимо....
Тоже не понял. На торговой точке должен стоять локальный сервер, который будет загружать с ЦОДа номенклатуру, цены, промо и так далее и раздавать это по кассам. В случае, если касса напрямую идет к базе в ЦОД - это проблема буквально ежедневная.
При наличии стабильной связи это вообще не проблема, зато снижение затрат на инфраструктуру точек вполне очевидное.
Для торговых точек, кои скорее всего ИП на франшизе, цена лицензий 1С окажется пугающей. Плюс что-то, в виде сервера.
Хотя возможно подойдет Мини Сервер. На 5 подключений. Но не знаю как он работает с торговым оборудованием и отраслевыми решениями.
Так как автор упоминает торговлю розничной одеждой, почти вся одежда сейчас маркируются. Перед продажей должен быть передан апи запрос до честного знака. Для запроса нужны сертификаты с цифровой подписью. А так же документы для передачи товара, нужны документы ЭДО.
Распределенная структура или даже РИБы здесь не подойдут. Нужна именно клиент-серверная структура.
А умеет ли 1С корректно работать при указанной Вами схемой, я не уверен.
Проблематичная схема в каждом магазине по сервачку.
На 60 магазинах дополнительных 60 точек отказа.
Как только отказались от сервачков в магазинах, авралы в админке стали значительно реже. И потребность в админах упала.
А обновление ПО? по 60 магазинам проверить 60 сервачков.
Не рационально.
Но если у вас план не быть уволенным. Остаться обновляльщиком.
Тогда конешн.
Согласен, поступило много комментариев касательно распределительной системы. Интересно, какой у них опыт работы с подобными системами и сколько точек в их инфраструктуре. У нас был опыт взаимодействия с клиентами, которые начинали с распределительной системы, но на момент обращения к нам имели всего 1-3 точки. В процессе расширения мы переводили их на централизованную систему, при этом все изменения проводились при поддержке и полном согласии специалистов 1С.
Несколько лет назад этот вариант еще использовался, но на данный момент у нас нет ни одного клиента, который бы так работал. Затраты на обслуживание каждой локальной точки значительно выше, а при синхронизации с центральной базой часто возникают сбои. Кроме того, клиенту необходимо видеть продажи и остатки в режиме реального времени, так как часто товары из магазинов отгружаются в том числе на маркетплейсы.
Ваша статья вызвала неоднозначное впечатление. У вас есть некоторая непоследовательность. Типичная для неаккуратного маркетинга.
Вы в технические проблемы записываете офисный пк и тут же предлагаете пользовательские Ryzen.
У вас в причинах зависания 1С описывается отсутствие средств на модернизацию и поддержку. А вы, простите, за бесплатно готовы провести все работы и обеспечивать долгосрочную работу инфраструктуры?
Ни в коем случае не хотел вас обидеть, но внимательный руководитель очень плохо отнесется к таким несовпадениям аргументации вашего, возможно прекрасного, предложения.
P.S. Ну и очень плохо сочетается новый MS SQL/Server и борьба с нелицензионным ПО.
В дата-центрах доступны в аренду серверы с процессорами Ryzen, и это не считается потребительским решением. Эти процессоры обладают высокой производительностью и отлично подходят для некоторых серверных задач, включая работу 1С.
Компании обычно уже тратят средства на обслуживание своей инфраструктуры, наша цель — помочь им делать это более эффективно. И всё верно — мы не делаем работы бесплатно)
Несмотря на некоторые трудности, использование лицензионного ПО все еще возможно. Кроме того, существуют альтернативы в виде свободного программного обеспечения, которые мы предлагаем использовать, чтобы снизить затраты и избежать проблем с нелицензионным софтом.
Интересно это всë начинает выглядеть, когда "магазинов" больше 1000....
Лет 20 назад на курсах Microsoft меня учили что
SQL-сервер,
домен-контроллер,
вместе - недопустимое сочетание из за разных требований к кешированию дисковых операций. Сейчас что-то изменилоь?
так вместе и не ставим, это разные вм
разные вм
замечательно. пробовали ли вы оценить потерю производительности БД и сервера приложений 1С за счет виртуализации ?
Если использовать современные серверы, то потерю производительности при работе с вм вы не заметите. У нас даже бывают споры с 1с-специалистами, которые просят развернуть 1с без виртуализации, считая, что так будет быстрее. Я считаю это пережитком прошлого, поэтому предлагаем развернуть систему с использованием виртуальных машин и, если не устроит скорость, за свой счёт перенесём все на физическую машину. За все время не было случаев, чтобы нас просили это сделать.
Если использовать современные серверы
то придется платить как за современные серверы + налог на импортозамещение.
рассмотрим другой аспект.
если будет всплеск нагрузки на 1С типа "акция + распродажа",
то кто лучше справится - виртуалка или bare metal ?
ps: "Например, в ноябре 2022 года" легалки 1С кто не обновлялся тоже получили сюрприз. и облачные 1С тоже.
У вас либо есть ресурсы, чтобы выдержать пиковые нагрузки, либо их нет, а физические они или виртуализованные - в подавляющем большинстве случаев не играет вообще никакой роли.
Современные сервера, это не hdd диски, процессоры не 6 поколения и память не ddr3... Сейчас на все оборудование действует налог на импортозамещение), даже на то, которое было ввезено три года назад.
Если говорить о вашем примере, то, на мой взгляд, разница в производительности будет минимальной или вовсе отсутствовать. Подчеркну, что это основано на нашем опыте работы с 1С. Есть проекты, где важна каждая миллисекунда, и в таких случаях мы не используем виртуализацию. Но именно в 1С мы с такими запросами не сталкивались. А вот если сервер выйдет из строя, время на восстановление с нуля существенно отличается в пользу виртуализации.
Не совсем понимаю причем тут 1с, которые не обновляли.
виртуалка или bare metal ?
Конечно bare metal. Процентов на 10%. Можно еще 1С кластер и СУБД не разносить и поставить на одной физической машине -- за счет shared memory еще процентов 10-20% можно будет выиграть. Только вот при резком росте нагрузки это не поможет. А вот управляемость, стоимость эксплуатации, отказоустойчивость, скорость восстановления и прочее, прочее сильно пострадают.
На мой взгляд лучше использовать виртуалки и при кратном росте нагрузок увеличивать их ресурсы и/или думать как масштабировать систему чтобы пережить пик.
Интересная история, а как разные вм на едином дисковос сторадже отражаются на требованиях к кешированию дисковых операций )?
Вас же спросили про оценку потери производительности, а не про будет ли это "быстро" работать. Конечно если брать сервера на виртуализацию с "запасом", то конечно работать будет, но в конечно счёте за это заплатит ваш клиент, ну момент, когда он вырастет из этого железа, и ему придётся доплачивать за обновление настанет раньше. А если говорить про арендуюмую/облачную инфраструктуру, не свою, то тут клиент просто платит всегда больше... но кого это волнует...
Ну а вещать sw vpn да ещё и на продуктивный сервер SQL, это ну вообще залет. Даже при парировании, что это разные ВМ, ну никак не умиляет нагрузки, причем при таком количествеи впн клиент-серверных коннекта как на сетевые интерфейсы, однозначно накладывающие деградацию на решения не на shared memory,. Ну и проц такое решение с впн отъедает ох как нормально...
Не зачёт по инфраструктуре.
Разные ВМ на одном дисковом хранилище и кеширование: Мы используем высокопроизводительные SSD с RAID-конфигурацией, что обеспечивает быстрый доступ к данным и снижает влияние ВМ друг на друга.
Оценка потери производительности и затраты для клиента: Проводим тщательный анализ нагрузок и подбираем оборудование без избыточного резервирования. Это позволяет избежать лишних затрат для клиента и обеспечивает запас для роста.
Арендуемая vs. собственная инфраструктура: Выбор между облаком и собственной инфраструктурой делается совместно с клиентом на основе экономической эффективности и специфических потребностей бизнеса.
Размещение VPN на продуктивном SQL-сервере: VPN-сервер и SQL-сервер находятся на разных виртуальных машинах с выделенными ресурсами. Это обеспечивает изоляцию нагрузок и предотвращает деградацию производительности. Также, если мы говорим именно про текущий пример, то при необходимости можно менять виртуальные машины между серверами или вообще все ВМ держать на одном сервере, если позволяет мощность сервера и общая нагрузка на сервисы.
В данной статье я привел рабочий и стабильный вариант планирования инфраструктуры у действующего клиента с 10 магазинами, складами, производством, офисами, маркетплейсами и интернет-магазином. Мы внимательно относимся к затратам клиента как на само оборудование, так и на обслуживание этой инфраструктуры.
А в RAM-диск 1С загружать не было такого?
такого опыта нет, да и в целом может это уже и не так необходимо если использовать NVMe диски
А зачем? Если только файловая БД, но это история не про средние и большие нагрузки. В клиент-серверном варианте и так оперативные данные БД в оперативке в кэше.
Что у 1С (не СУБД) требовательно к I/O я вот так сходу даже придумать не могу. Сеансовые данные разве что, но они и так мапятся в RAM.
А зачем?
продлить жизнь файловой БД 1С, оттянуть внедрение MS SQL или PostgreSQL
предположительно на RAM-диске блокировки будуть ставиться быстрее и освобождаться тоже быстрее.
Будет реализовано за счет угрозы потери данных, что очень рискованное решение на мой взгляд. По опыту перетаскивание файловой БД с HDD на SSD, потом на NVMe очень не надолго дает отсрочку от принятия решения к переезду на SQL. Полгода-год. Мое мнение, что овчинка не стоит выделки надо решать проблему радикально.
Если мне память не изменяет, то 1Совские блокировки и так хранятся в памяти соответствующего менеджера кластера.
регламентированные технологические перерывы и выгрузки в .dt сгладят проблему. это быстро. если выгружать тоже в RAM disk и растаскивать SSD -> HDD -> сетевая хранилка. NVME не рассматриваю, там цифры iops похожи на обман либо ее так не настроить для реальных задач на реальном оборудовании.
очень не надолго дает отсрочку [...] Полгода-год
это очень большой срок. сдохнет либо ишак либо падишах либо 1С.
насколько я помню эту дрянь-программу, у файловых баз нет "менеджера кластера".
Стабильных решений для использования. Ram как дисковые накопители на рынке нет, особенно для продуктивный сред уровня business critical. Было одно время очень интересное решение intel optane pmem на памяти 3d-xpoint, (впрочем как ssd), но интел прикрыл эту тему, почему то. Для энтузиастов можно запрыгнуть в "уходящий поезд" и попробовать оторвать на рынок подобные решения...
"...Середина 2022 г. — Интел сворачивает бизнес-направление Optane Memory (в свете падения квартальной выручки на 22 % год к году, компания просто не может поддерживать все перспективные технологии, требующие больших инвестиций в R&D)". Вики такую версию выдает.
-Как построить инфраструктуру, чтобы 1С не зависело?
-Не использовать решения от 1С!
Например, в ноябре 2022 года , многие компании, использовавшие нелицензионную 1С, столкнулись с массовыми сбоями в ходе работы программы и ее обновления, что повлекло за собой длительные (дни и даже недели) простои в работе и огромные финансовые потери.
Стоит отметить, что с проблемой столкнулись и те, кто был 100% лицензирован. Мы все помним этот черный вторник.
где на 1С завязаны все сканеры, кассовая техника, терминалы оплаты, терминалы сбора данных (ТСД) и системы маркировки товаров — и все это должно работать безупречно.
но в вашей схеме указан сервер РДП, если вы подключаете все оборудование через маппинг в РДП-сессии, то никогда не добьётесь стабильности в работе этого оборудования.
Оно всегда будет отваливаться. Драйверы на принтеры чеков вечно норовят уронить спуллер. Зависшие РДП-сессии нужно выбивать с сервера, при этом может сбиваться проброс внешних устройств.
А это все время, люди стоят на кассе, ждут. Тонкий клиент здесь подходит лучше. Бонусом вы получаете меньше зависимости от МС продуктов. В нынешние времена это весомый аргумент.
В схеме действительно присутствует RDP, однако это не означает, что на торговых точках мы не используем тонкие клиенты. Все верно, на торговых точках тонкие клиенты и подключенное к ним оборудование работают гораздо стабильнее. RDP в большей степени предназначен для офисных сотрудников и тех, кто работает удалённо.
1С зависает, а бизнес теряет деньги: как построить ИТ-инфраструктуру, чтобы этого избежать