|
1С Web сервер для Linux развернуть в Kubernetes? | ☑ | ||
---|---|---|---|---|
0
pvase
23.02.21
✎
14:02
|
Здравствуйте. Есть задача перевести сервер 1С на Linux в Kubernetes. Делал ли кто такое, это возможно? Если есть какая-то информация относительно этого поделитесь пожалуйста. Спасибо.
|
|||
1
fisher
23.02.21
✎
14:08
|
А сервер СУБД?
|
|||
2
fisher
23.02.21
✎
14:08
|
Отдельно жить остается?
|
|||
3
fisher
23.02.21
✎
14:25
|
Если я правильно понял, то от тебя примерно это хотят? http://catalog.mista.ru/1c/articles/1283329/
Там чуваки решали задачу повышения отказоустойчивости веб-сервисов с помощью Kubernetes. Но я так и не понял, как решался вопрос серверных лицензий при запихивании в докер. На прямой вопрос был ответ "Если сервер лицензирования находится в одной подсети, все можно легко организовать, просто прописав маршруты получения этих лицензий". Но это же про клиентские лицензии! Ну и вообще довольно стремно десятки серверов 1С в одном кластере. Его не попучит? :) |
|||
4
Провинциальный 1сник
23.02.21
✎
14:38
|
Хрень какая-то. В случае использования 1с в архитектуре клиент-сервер с доступом через роль веб-сервера сводится к примитивному ретранслятору и упаковщику. Соответственно, с намного большей вероятностью упадет сам сервер 1с, чем веб-сервер. И городить огород с отказоустойчивым веб-сервером при наличии единой точки отказа в виде кластера 1с как-то нелогично.
А при использовании веб-публикации файловой базы это вообще смешно. |
|||
5
fisher
23.02.21
✎
14:46
|
(3) +
Блииин! Кажись до меня дошло! Это ж линух! А на линухе до сих пор работает фича, что на одном рабочем процессе и небольшом количестве сеансов платформа не ругается на отсутствие серверного ключа. Для веб-сервисов - идеально. Гениально! |
|||
6
fisher
23.02.21
✎
14:48
|
Концептуально только один момент мне непонятен. Как именно выполняется балансировка веб-сервисов между инстансами. В идеале бы было не более одного веб-сервиса на инстанс. Но как этого добиться?
|
|||
7
fisher
23.02.21
✎
15:07
|
(6) + Бегло погуглил, вроде как для Kubernetes это типичная задача и все учтено могучим ураганом: https://kubernetes.io/docs/concepts/services-networking/ingress/
|
|||
8
МихаилМ
23.02.21
✎
15:13
|
||||
9
fisher
23.02.21
✎
15:14
|
Реально очень красивое решение получается. Веб-процессы бегут изолировано, можно настроить динамическое выделение мощностей под увеличение нагрузки, а если таки ляжет - поднимется автоматом.
Критично только если ляжет менеджер кластера или СУБД. Но это уже такое. Тем паче что для "отдающих" сервисов можно отдельные реплики настроить. |
|||
10
fisher
23.02.21
✎
15:17
|
(8) Kubernetes и другие виды контейнеров поддерживает плюс виртуалки.
|
|||
11
Почему 1С
24.02.21
✎
10:48
|
Осталось только отладить процесс помещения 1с хозяйства в Docker, на выходных только смотрел митап по поводу настройки контейнера под 1с, что то впечатления - сложно и криво.
https://www.youtube.com/watch?v=kNj5THH5lXI&t=6648s |
|||
12
Garykom
гуру
24.02.21
✎
10:51
|
Сервер 1С под линукс только с Постгрес умеет?
|
|||
13
ДенисЧ
24.02.21
✎
10:52
|
(12) Да.
|
|||
14
Фрэнки
24.02.21
✎
10:53
|
(12) э...
а почему такое спрашиваешь? |
|||
15
ansh15
24.02.21
✎
11:03
|
(12) Oracle и DB2 тоже можно, но кто ж их специально для этого купит. Експрессы тоже можно, но это даже не смешно.
Так что, фактически -да, PostgreSQL. |
|||
16
Garykom
гуру
24.02.21
✎
11:08
|
(15) Вот это и хотел уточнить
(14) Postgres в реальности на практике не айс, трабл с админством слишком много и разных неприятных глюков Например ваяешь ты в серверной базе на рабочем компе (без упсы) и херак свет отрубили. И привет "FATAL: the database system is starting up." |
|||
17
ДенисЧ
24.02.21
✎
11:08
|
https://v8.1c.ru/platforma/mnogoplatformennost/#1
Особенности рабочих серверов под управлением Linux не могут взаимодействовать с СУБД Microsoft SQL Server, |
|||
18
ansh15
24.02.21
✎
11:41
|
(16) С MS SQL такого, конечно, никогда не бывает. Он заботливо сохраняет все данные до следующего включения, ни упс не нужен, ни ионистор на SSD...
|
|||
19
Garykom
гуру
24.02.21
✎
11:47
|
(18) гораздо реже такие траблы с MSSQL
и админка у PostgreSQL ужасна через браузер да еще и глючит с восстановлением баз Короче в проде PostgreSQL вполне нормален если за ним следить, для разработки/отладки не очень. Речь про последние/свежие версии, со старыми все было сильно лучше когда лет так 10 назад из Java работал |
|||
20
fisher
24.02.21
✎
11:52
|
(16) Странно. С конфигом не шаманил? Разные глупцы в интернетах советуют отключать упреждающую запись в конфиге типа "для ускорения".
|
|||
21
fisher
24.02.21
✎
12:00
|
fsync (boolean)
Если этот параметр установлен, сервер PostgreSQL старается добиться, чтобы изменения были записаны на диск физически, выполняя системные вызовы fsync() или другими подобными методами (см. wal_sync_method). Это даёт гарантию, что кластер баз данных сможет вернуться в согласованное состояние после сбоя оборудования или операционной системы. Хотя отключение fsync часто даёт выигрыш в скорости, это может привести к неисправимой порче данных в случае отключения питания или сбоя системы. Поэтому отключать fsync рекомендуется, только если вы легко сможет восстановить всю базу из внешнего источника. |
|||
22
Garykom
гуру
24.02.21
✎
12:02
|
(20) та нет как раз ошибка расхождения упреждающей с основной, оно подождать и обычно запускается, на рабочем сервере это норма, там сбои редки
а вот на своем или домашнем такое поведение слегка бесит, у меня ноут например любит на последних биосах раз/два в неделю вырубаться (точнее перезагружаться) жестко |
|||
23
Garykom
гуру
24.02.21
✎
12:04
|
(22)+ Вот и думал на Oracle или IBM DB2 перейти, там вроде Экспресс/Девелопер версии вполне функциональны
|
|||
24
fisher
24.02.21
✎
12:05
|
(22) Не, ну если СУБД уверена что сбросил данные на диск, а под копотом это не так и данные крашатся при блэкауте, то тут уже не в СУБД дело. Тут любая СУБД скажет "ой".
|
|||
25
Garykom
гуру
24.02.21
✎
12:07
|
(24) Дык PostgreSQL долго после ой восстанавливается, я бы предпочел заново базу из бэкапа загрузить а не ждать.
Причем весь сервер того даже новую базу не але |
|||
26
fisher
24.02.21
✎
12:11
|
(25) Ну, некоторый блеск и нищета опенсорса торчат наружу, это да. Так наплевательски с ним обращаться как с сиквелом не выйдет. В реальном продакшене, как я слышал, на каждую базу отдельный кластер постгревый развертывают. Тогда сразу ряд проблем уходит.
|
|||
27
Йохохо
24.02.21
✎
12:15
|
(26) ну в опенсорц часто путают включение вал с включением фсинк, по этому разные замеры производительности и разброд и шатания)
|
|||
28
fisher
24.02.21
✎
12:24
|
(26) + Во-первых, для кластера целиком из коробки доступны нормальные бинарные бэкапы, во-вторых можно каждую базу затюнить под ее профиль нагрузки. Ну и плюс меньше вероятность, что сразу все базы засуспектятся. В оракле, ЕМНИП, похожая концепция - каждая база обслуживается отдельным набором сервисов. Хотя мое знакомство с ораклом было шапочным, поэтому могу ошибаться.
|
|||
29
Garikk
24.02.21
✎
12:27
|
(26) <Ну, некоторый блеск и нищета опенсорса торчат наружу, это да>
Это не блески и нищета, а отсутствие DBA у тех кто обычно такие СУБД юзает в оракле глюков не меньше, но обычно их эксплуатируют там где штатный дба есть |
|||
30
Garykom
гуру
24.02.21
✎
12:32
|
(29) чем поможет dba если в PostgreSQL в момент бэкапа низзя средствами 1С конфу/базу/метаданные обновлять
Бэкап то будет хороший а вот база того |
|||
31
Garikk
24.02.21
✎
12:44
|
(30) < в момент бэкапа низзя средствами 1С конфу/базу/метаданные обновлять >
а что в какойто базе можно? |
|||
32
Garykom
гуру
24.02.21
✎
12:53
|
(31) Бэкап средствами PostgreSQL проходит в фоновом режиме, работать штатно в 1С в это время можно.
Но если через конфигуратор сделать изменение метаданных или просто типовое обновление конфы запустить и там метаданные в базе меняются то упс. Т.е. сервер 1С не понимает и не запрещает на PostgreSQL изменение таблиц sql базы, доступ типа монопольный а по факту нет и ибо субд в фоне бэкапит и изменение не проходит и приехали База то есть но в недоделанном виде и 1С ее больше не хотит понимать |
|||
33
Garykom
гуру
24.02.21
✎
12:55
|
(32)+ На MSSQL подобного поведения не наблюдал, плевать было на время/длительность бэкапов, всегда запускал обновление конф/баз и все ок
На PostgreSQL низзя чтобы пересеклось время бэкапа средствами субд и изменение/обновление конфы |
|||
34
Garikk
24.02.21
✎
12:57
|
(32) ну как ты сам то считаешь каким чудным образом mssql может обеспечить целостность данных во время бекапа если не приостанавливать операции по базе?
|
|||
35
Garykom
гуру
24.02.21
✎
12:58
|
(34) Ты в курсе как бэкапы делаются и целостность данных а конкретно какие данные (по времени) попадут в бэкап?
|
|||
36
fisher
24.02.21
✎
12:59
|
(29) Да-да. Чем сильнее СУБД поворачивается жопой, тем более сильный админ нужен для разворачивания ее лицом.
(32) Интересно. > База то есть но в недоделанном виде и 1С ее больше не хотит понимать Не понял. То есть еще и база крашится после такого? |
|||
37
Garykom
гуру
24.02.21
✎
13:00
|
(36) Сама база PosgtreSQL работает, но сервер 1С с ней больше не але, там какие то служебные таблицы не те данные
|
|||
38
ansh15
24.02.21
✎
13:05
|
(37) Как при неудавшемся динамическом обновлении?
|
|||
39
fisher
24.02.21
✎
13:08
|
(37) Другими словами при реструктуризации происходит какой-то сбой, если в этот момент делается бэкап. Прекрасно.
Делать реструктуризацию во время бэкапа это плохая идея. Но ожидалось бы просто отваливание бэкапа, а не базы :) |
|||
40
Garikk
24.02.21
✎
13:08
|
(35) ну как я себе представляю бекап в mssql
1) ты тыркаешь в бекап 2) отмечается последняя транзакция до 3) все новые транзакции на изменения дублируются в отдельный лог 4) бекап завершается 5) лог из п.3 накатывается на боевые данные вопрос лишь в том, хватит ли места базе чтобы в этот лог влезали транзакции до тех пор пока бекап не завершился а в pgsql обычные админы делают pgdump которые такие фокусы не умеет...в итоге ломают консистентность. я конечно не dba, но сдается мне что схему как с mssql сделать тоже вполне реально |
|||
41
fisher
24.02.21
✎
13:11
|
(40) Нет отдельного лога. Просто очередная контрольная точка откладывается до завершения бэкапа. То есть на диске остается старое состояние, которое и бэкапится, а все изменения делаемые во время бэкапа остаются в памяти.
|
|||
42
Garikk
24.02.21
✎
13:15
|
(41) ну я тоже самое и описал
<а все изменения делаемые во время бэкапа остаются в памяти.> я это и назвал отдельным логом. Памяти может и не хватить, если 50гб изменений залить пока тем база на ленту бекапится...её в любом случае надо кудато скидывать |
|||
43
Garikk
24.02.21
✎
13:15
|
ну это не суть, я не дба всётаки, важен принцип
а обычные бекап в pg это select * from * > бэкапчик.sql |
|||
44
Garikk
24.02.21
✎
13:16
|
тут как грится, каков админ такой и результат, на базу тут не стоит гнать
|
|||
45
spiller26
24.02.21
✎
13:19
|
Я тоже хочу попробовать docker, всё никак руки не доходят.
Где-то видел даже под винду докер делали, правда с MySQL, типа для всякой тестовой фигни. (MICROSOFT SQL SERVER DOCKER 1C https://www.youtube.com/watch?v=WhamkTdBldA) |
|||
46
fisher
24.02.21
✎
13:23
|
(42) Ну, хозяин - барин. Не мне же тебе запрещать называть логом то, что логом не является. Но не ожидай, что тебя с такой гибкой терминологией окружающие будут с полуслова понимать :)
(43) Это издержки pg_dump. Который судя по всему делается тупо по версиям данных в таблицах, а не на страничном уровне. Но вот почему при этом ломается база для кластера - загадка. Пишут, что pg_basebackup делает "бинарный" бэкап кластера. Но в доке написано, что он использует механизмы репликации. Поэтому я не уверен, что и там этой беды нет. И еще я слышал, что в "энтерпрайзных" поделиях на базе постгреса запилена альтернативная реализация бэкапа. И это "жжжж", очевидно, неспроста. |
|||
47
fisher
24.02.21
✎
13:25
|
"Но вот почему при этом ломается база для кластера 1С - загадка."
|
|||
48
Garykom
гуру
24.02.21
✎
13:28
|
(38) угу, очень похоже
|
|||
49
fisher
24.02.21
✎
13:29
|
Стоп-стоп. А чего там такого пишет при проблемах из-за динамического обновления? Есть точное описание ошибки?
|
|||
50
Garykom
гуру
24.02.21
✎
13:31
|
(39) дык меня тоже это прикололо что сама база рухнула, хорошо что хоть бэкап с последними данными поднялся и просто заново обновление накатил
|
|||
51
fisher
24.02.21
✎
13:39
|
(45) В (8) ссылка на видео про докер от ЗлогоБобра, который "наше всё".
|
|||
52
pvase
24.02.21
✎
14:37
|
Все верно. У нас будет 3 среды: 1 - SQL база (находится к кластере серверов MS SQL). 2 - Сервер приложений находиться отдельно, есть главный сервер и дополнительные (типа кластер по нагрузке). 3 - Сервер WEB 1С (UBuntu + Apache все на Кубере).
|
|||
53
pvase
24.02.21
✎
14:39
|
Причем сервер 1С будет на Windows, поэтому проблем с MS SQL не должно возникнуть.
p.s. Лицензирование нас волнует в последнюю очередь в этом вопросе. Главная задача - уйти от терминалов и получить масштибуремое решение по клиентам. У нес сетка по стране разбросана, сейчас все в терминалах, но это очень и очень ресурсоемко и очень и очень немасштибуремо. |
|||
54
Garykom
гуру
24.02.21
✎
14:42
|
(53) Так с сервером 1С зачем несколько веб-серверов то?
|
|||
55
Garykom
гуру
24.02.21
✎
14:42
|
(54)+ Я еще понимаю файловый вариант через веб-сервер, когда несколько апачей на разных портах поднимают чтобы в одно подключение к базе не упираться
|
|||
56
Йохохо
24.02.21
✎
14:43
|
(52) Вы оркестровщик с балансировщиком не перепутали?
|
|||
57
pvase
24.02.21
✎
14:49
|
(52) Возможно, в Кубере я несколько дней только, и то по заданию "Партии". У нас проблема в нагрузке на терминальные сервера + их постоянная поддержка, вот и решили уйти от них на WEB, к тому же готовиться большой проект по обменам, сразу переписываем все где можно на API, а тут снова нужен WEB.
|
|||
58
pvase
24.02.21
✎
14:51
|
обмен через Kafka попробуем запустить.
|
|||
59
fisher
24.02.21
✎
14:53
|
(53) Отдельно апачи вы в кубер не засунете. Да и вообще при такой постановке вопроса "кубер" выглядит больше "як примха". Будет больше головняка, чем пользы.
|
|||
60
pvase
24.02.21
✎
14:57
|
(59) Для 1С возможно, для Апача - как раз то что надо. Но мне дали задание разобраться и предоставить возможность работы WEB сервере 1С в Кубере. В Докере нашел но это немного не то.
|
|||
61
fisher
24.02.21
✎
15:05
|
(60) Да, я затупил. Должно получиться.
|
|||
62
fisher
24.02.21
✎
15:17
|
(57) Вообще, очень странно, что у вас тонкие клиенты создают такую нагрузку на терминальные сервера. Либо у вас не тонкие клиенты (и тогда в веб вы не уйдете), либо основную нагрузку дает не 1С.
|
|||
63
ansh15
24.02.21
✎
16:09
|
(47) Запускал одновременное выполнение реструктуризации таблиц ИБ из ТиИ и pg_dump(однопоточно).
Когда, при реструктуризации, выполняются DROP TABLE, некоторые из них могут быть в состоянии waitig. Если ожидание слишком долгое, то 1С выдает ошибку конфликта блокировок с завершением работы. Правда, мне базу испортить не удалось. Наверное, в иных случаях, может и портиться. |
|||
64
Garykom
гуру
24.02.21
✎
16:12
|
(63) ТиИ не портит таблицы а вот обновление с новыми метаданными портит
|
|||
65
Вафель
24.02.21
✎
16:12
|
под каждого клиента веб сервиса отдельный сервер 1с хотите поднимать?
|
|||
66
Garykom
гуру
24.02.21
✎
16:12
|
(64)+ Но бэкап должен быть долгий, на большой базе и тормозном сервере
|
|||
67
ansh15
24.02.21
✎
16:22
|
(66) Да, согласен.
1С, в качестве способа обхода, просто предложит так не делать(если у них спросить) |
|||
68
timurhv
24.02.21
✎
16:23
|
(3) есть механизмы проброса серверных ключей по сети, например USB Redirector. По-моему, клиент под Linux бесплатен.
(5) веб-сервисы не используют лицензию |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |