Здравствуйте. Есть задача перевести сервер 1С на  Linux в Kubernetes. Делал ли кто такое, это возможно? Если есть какая-то информация относительно этого поделитесь пожалуйста. Спасибо.

А сервер СУБД?

Отдельно жить остается?

Если я правильно понял, то от тебя примерно это хотят? http://catalog.mista.ru/1c/articles/1283329/
Там чуваки решали задачу повышения отказоустойчивости веб-сервисов с помощью Kubernetes. Но я так и не понял, как решался вопрос серверных лицензий при запихивании в докер. На прямой вопрос был ответ "Если сервер лицензирования находится в одной подсети, все можно легко организовать, просто прописав маршруты получения этих лицензий". Но это же про клиентские лицензии! Ну и вообще довольно стремно десятки серверов 1С в одном кластере. Его не попучит? :)

Хрень какая-то. В случае использования 1с в архитектуре клиент-сервер с доступом через роль веб-сервера сводится к примитивному ретранслятору и упаковщику. Соответственно, с намного большей вероятностью упадет сам сервер 1с, чем веб-сервер. И городить огород с отказоустойчивым веб-сервером при наличии единой точки отказа в виде кластера 1с как-то нелогично.
А при использовании веб-публикации файловой базы это вообще смешно.

(3) +
Блииин! Кажись до меня дошло! Это ж линух! А на линухе до сих пор работает фича, что на одном рабочем процессе и небольшом количестве сеансов платформа не ругается на отсутствие серверного ключа. Для веб-сервисов - идеально. Гениально!

Концептуально только один момент мне непонятен. Как именно выполняется балансировка веб-сервисов между инстансами. В идеале бы было не более одного веб-сервиса на инстанс. Но как этого добиться?

(6) + Бегло погуглил, вроде как для Kubernetes это типичная задача и все учтено могучим ураганом: https://kubernetes.io/docs/concepts/services-networking/ingress/

https://www.youtube.com/watch?v=ucfaGkG3wd8

Реально очень красивое решение получается. Веб-процессы бегут изолировано, можно настроить динамическое выделение мощностей под увеличение нагрузки, а если таки ляжет - поднимется автоматом.
Критично только если ляжет менеджер кластера или СУБД. Но это уже такое. Тем паче что для "отдающих" сервисов можно отдельные реплики настроить.

(8) Kubernetes и другие виды контейнеров поддерживает плюс виртуалки.

Осталось только отладить процесс помещения 1с хозяйства в Docker, на выходных только смотрел митап по поводу настройки контейнера под 1с, что то впечатления - сложно и криво.
https://www.youtube.com/watch?v=kNj5THH5lXI&t=6648s

Сервер 1С под линукс только с Постгрес умеет?

(12) Да.

(12) э...
а почему такое спрашиваешь?

(12) Oracle и DB2 тоже можно, но кто ж их специально для этого купит. Експрессы тоже можно, но это даже не смешно.
Так что, фактически -да, PostgreSQL.

(15) Вот это и хотел уточнить

(14) Postgres в реальности на практике не айс, трабл с админством слишком много и разных неприятных глюков
Например ваяешь ты в серверной базе на рабочем компе (без упсы) и херак свет отрубили.
И привет "FATAL: the database system is starting up."

https://v8.1c.ru/platforma/mnogoplatformennost/#1

Особенности рабочих серверов под управлением Linux
не могут взаимодействовать с СУБД Microsoft SQL Server,

(16) С MS SQL такого, конечно, никогда не бывает. Он заботливо сохраняет все данные до следующего включения, ни упс не нужен, ни ионистор на SSD...

(18) гораздо реже такие траблы с MSSQL
и админка у PostgreSQL ужасна через браузер да еще и глючит с восстановлением баз

Короче в проде PostgreSQL вполне нормален если за ним следить, для разработки/отладки не очень.
Речь про последние/свежие версии, со старыми все было сильно лучше когда лет так 10 назад из Java работал

(16) Странно. С конфигом не шаманил? Разные глупцы в интернетах советуют отключать упреждающую запись в конфиге типа "для ускорения".

fsync (boolean)
Если этот параметр установлен, сервер PostgreSQL старается добиться, чтобы изменения были записаны на диск физически, выполняя системные вызовы fsync() или другими подобными методами (см. wal_sync_method). Это даёт гарантию, что кластер баз данных сможет вернуться в согласованное состояние после сбоя оборудования или операционной системы.
Хотя отключение fsync часто даёт выигрыш в скорости, это может привести к неисправимой порче данных в случае отключения питания или сбоя системы. Поэтому отключать fsync рекомендуется, только если вы легко сможет восстановить всю базу из внешнего источника.

(20) та нет как раз ошибка расхождения упреждающей с основной, оно подождать и обычно запускается, на рабочем сервере это норма, там сбои редки
а вот на своем или домашнем такое поведение слегка бесит, у меня ноут например любит на последних биосах раз/два в неделю вырубаться (точнее перезагружаться) жестко

(22)+ Вот и думал на Oracle или IBM DB2 перейти, там вроде Экспресс/Девелопер версии вполне функциональны

(22) Не, ну если СУБД уверена что сбросил данные на диск, а под копотом это не так и данные крашатся при блэкауте, то тут уже не в СУБД дело. Тут любая СУБД скажет "ой".

(24) Дык PostgreSQL долго после ой восстанавливается, я бы предпочел заново базу из бэкапа загрузить а не ждать.
Причем весь сервер того даже новую базу не але

(25) Ну, некоторый блеск и нищета опенсорса торчат наружу, это да. Так наплевательски с ним обращаться как с сиквелом не выйдет. В реальном продакшене, как я слышал, на каждую базу отдельный кластер постгревый развертывают. Тогда сразу ряд проблем уходит.

(26) ну в опенсорц часто путают включение вал с включением фсинк, по этому разные замеры производительности и разброд и шатания)

(26) + Во-первых, для кластера целиком из коробки доступны нормальные бинарные бэкапы, во-вторых можно каждую базу затюнить под ее профиль нагрузки. Ну и плюс меньше вероятность, что сразу все базы засуспектятся. В оракле, ЕМНИП, похожая концепция - каждая база обслуживается отдельным набором сервисов. Хотя мое знакомство с ораклом было шапочным, поэтому могу ошибаться.

(26) <Ну, некоторый блеск и нищета опенсорса торчат наружу, это да>
Это не блески и нищета, а отсутствие DBA у тех кто обычно такие СУБД юзает
в оракле глюков не меньше, но обычно их эксплуатируют там где штатный дба есть

(29) чем поможет dba если в PostgreSQL в момент бэкапа низзя средствами 1С конфу/базу/метаданные обновлять
Бэкап то будет хороший а вот база того

(30) < в момент бэкапа низзя средствами 1С конфу/базу/метаданные обновлять >
а что в какойто базе можно?

(31) Бэкап средствами PostgreSQL проходит в фоновом режиме, работать штатно в 1С в это время можно.
Но если через конфигуратор сделать изменение метаданных или просто типовое обновление конфы запустить и там метаданные в базе меняются то упс.

Т.е. сервер 1С не понимает и не запрещает на PostgreSQL изменение таблиц sql базы, доступ типа монопольный а по факту нет и ибо субд в фоне бэкапит и изменение не проходит и приехали
База то есть но в недоделанном виде и 1С ее больше не хотит понимать

(32)+ На MSSQL подобного поведения не наблюдал, плевать было на время/длительность бэкапов, всегда запускал обновление конф/баз и все ок
На PostgreSQL низзя чтобы пересеклось время бэкапа средствами субд и изменение/обновление конфы

(32) ну как ты сам то считаешь каким чудным образом mssql может обеспечить целостность данных во время бекапа если не приостанавливать операции по базе?

(34) Ты в курсе как бэкапы делаются и целостность данных а конкретно какие данные (по времени) попадут в бэкап?

(29) Да-да. Чем сильнее СУБД поворачивается жопой, тем более сильный админ нужен для разворачивания ее лицом.
(32) Интересно.
> База то есть но в недоделанном виде и 1С ее больше не хотит понимать
Не понял. То есть еще и база крашится после такого?

(36) Сама база PosgtreSQL работает, но сервер 1С с ней больше не але, там какие то служебные таблицы не те данные

(37) Как при неудавшемся динамическом обновлении?

(37) Другими словами при реструктуризации происходит какой-то сбой, если в этот момент делается бэкап. Прекрасно.
Делать реструктуризацию во время бэкапа это плохая идея. Но ожидалось бы просто отваливание бэкапа, а не базы :)

(35) ну как я себе представляю бекап в mssql
1) ты тыркаешь в бекап
2) отмечается последняя транзакция до
3) все новые транзакции на изменения дублируются в отдельный лог
4) бекап завершается
5) лог из п.3 накатывается на боевые данные
вопрос лишь в том, хватит ли места базе чтобы в этот лог влезали транзакции до тех пор пока бекап не завершился

а в pgsql обычные админы делают pgdump которые такие фокусы не умеет...в итоге ломают консистентность.
я конечно не dba, но сдается мне что схему как с mssql сделать тоже вполне реально

(40) Нет отдельного лога. Просто очередная контрольная точка откладывается до завершения бэкапа. То есть на диске остается старое состояние, которое и бэкапится, а все изменения делаемые во время бэкапа остаются в памяти.

(41) ну я тоже самое и описал
<а все изменения делаемые во время бэкапа остаются в памяти.>
я это и назвал отдельным логом.

Памяти может и не хватить, если 50гб изменений залить пока тем база на ленту бекапится...её в любом случае надо кудато скидывать

ну это не суть, я не дба всётаки, важен принцип

а обычные бекап в pg это select * from * > бэкапчик.sql

тут как грится, каков админ такой и результат, на базу тут не стоит гнать

Я тоже хочу попробовать docker, всё никак руки не доходят.
Где-то видел даже под винду докер делали, правда с MySQL, типа для всякой тестовой фигни. (MICROSOFT SQL SERVER DOCKER 1C https://www.youtube.com/watch?v=WhamkTdBldA)

(42) Ну, хозяин - барин. Не мне же тебе запрещать называть логом то, что логом не является. Но не ожидай, что тебя с такой гибкой терминологией окружающие будут с полуслова понимать :)
(43) Это издержки pg_dump. Который судя по всему делается тупо по версиям данных в таблицах, а не на страничном уровне. Но вот почему при этом ломается база для кластера - загадка.
Пишут, что pg_basebackup делает "бинарный" бэкап кластера. Но в доке написано, что он использует механизмы репликации. Поэтому я не уверен, что и там этой беды нет. И еще я слышал, что в "энтерпрайзных" поделиях на базе постгреса запилена альтернативная реализация бэкапа. И это "жжжж", очевидно, неспроста.

"Но вот почему при этом ломается база для кластера 1С - загадка."

(38) угу, очень похоже

Стоп-стоп. А чего там такого пишет при проблемах из-за динамического обновления? Есть точное описание ошибки?

(39) дык меня тоже это прикололо что сама база рухнула, хорошо что хоть бэкап с последними данными поднялся и просто заново обновление накатил

(45) В (8) ссылка на видео про докер от ЗлогоБобра, который "наше всё".

Все верно. У нас будет 3 среды: 1 - SQL база (находится к кластере серверов MS SQL). 2 - Сервер приложений находиться отдельно, есть главный сервер и дополнительные (типа кластер по нагрузке). 3 - Сервер WEB 1С (UBuntu + Apache все на Кубере).

Причем сервер 1С будет на Windows, поэтому проблем с MS SQL не должно возникнуть.
p.s. Лицензирование нас волнует в последнюю очередь в этом вопросе. Главная задача - уйти от терминалов и получить масштибуремое решение по клиентам. У нес сетка по стране разбросана, сейчас все в терминалах, но это очень и очень ресурсоемко и очень и очень немасштибуремо.

(53) Так с сервером 1С зачем несколько веб-серверов то?

(54)+ Я еще понимаю файловый вариант через веб-сервер, когда несколько апачей на разных портах поднимают чтобы в одно подключение к базе не упираться

(52) Вы оркестровщик с балансировщиком не перепутали?

(52) Возможно, в Кубере я несколько дней только, и то по заданию "Партии". У нас проблема в нагрузке на терминальные сервера + их постоянная поддержка, вот и решили уйти от них на WEB, к тому же готовиться большой проект по обменам, сразу переписываем все где можно на API, а тут снова нужен WEB.

обмен через Kafka попробуем запустить.

(53) Отдельно апачи вы в кубер не засунете. Да и вообще при такой постановке вопроса "кубер" выглядит больше "як примха". Будет больше головняка, чем пользы.

(59) Для 1С возможно, для Апача - как раз то что надо. Но мне дали задание разобраться и предоставить возможность работы WEB сервере 1С в Кубере. В Докере нашел но это немного не то.

(60) Да, я затупил. Должно получиться.

(57) Вообще, очень странно, что у вас тонкие клиенты создают такую нагрузку на терминальные сервера. Либо у вас не тонкие клиенты (и тогда в веб вы не уйдете), либо основную нагрузку дает не 1С.

(47) Запускал одновременное выполнение реструктуризации таблиц ИБ из ТиИ и pg_dump(однопоточно).
Когда, при реструктуризации, выполняются DROP TABLE, некоторые из них могут быть в состоянии waitig.
Если ожидание слишком долгое, то 1С выдает ошибку конфликта блокировок с завершением работы.
Правда, мне базу испортить не удалось. Наверное, в иных случаях, может и портиться.

(63) ТиИ не портит таблицы а вот обновление с новыми метаданными портит

под каждого клиента веб сервиса отдельный сервер 1с хотите поднимать?

(64)+ Но бэкап должен быть долгий, на большой базе и тормозном сервере

(66) Да, согласен.
1С, в качестве способа обхода, просто предложит так не делать(если у них спросить)

(3) есть механизмы проброса серверных ключей по сети, например USB Redirector. По-моему, клиент под Linux бесплатен.
(5) веб-сервисы не используют лицензию