всё правильно сказали выше: дыра - в сливе. если банк хоть "не всем, а только нужным", то левое приложение - всем кто заплатит сольет. а зачем кому то знать - сколько у меня на счету и сколько проходит за месяц
кто-то пользуется одним банком? в марте кэшбеки в "1-ом банке одни, во 2-ом другие", в апреле частично наоборот... ибо а зачем терять даже ту копеечку, если она (например) в разы превышает затраты на сигареты и выпивку
считаю "приложение умеет подтягивать из банков" - плохой идеей. это ж очевидная дыра
я тоже в табличке веду, гибкость повыше чем у приложух... не хватит гибкости - можно свою написать. единственно считаю разбивать например продукты на "Мясо-конфеты" - уже маразм.. да и зачем мне помнить 3-го или 12-го числа купил продукты на 2т.р. ... в-общем не стоит сильно детализироваться - времени много тратится
поверьте, приятнее часы подождать и продолжить, чем потерять всё, когда (недо)оператор ДЦ ловит атаку... был прецедент пару лет назад (не скажу с кем), благо архивы сливали себе не доверяя оператору (а ведь многие даже денюжку берут за хранение архивов в ДЦ)
в случае с несколькими провайдерами также удобно делить трафик по типу... простейший пример (рассмотрим только внешний, без всяких SMB,mail,etc.): весь HTTP(s) трафик через ЦО (без всяких прокси) по каналу с шифрованием (чтобы ИБ посмотрели что там :) ), а вот видео трафик через резервного провайдера сразу в интернет (допустим у нас нет своего ВКС центра в периметре, подключаемся к чужим облачным) если в нем нет ничего секретного - сразу и шифрующие роутеры разгружаются и каналы. В-общем PBR вещь действительно удобная, но ведь реализована и документировано всё еще в начале века, если не в прошлом... ничего нового не увидел :)
почему-то многие считают, что удобнее всё, что относится к 1С собрать в рамках одного сервера и одной ОС, Windows самом собой. вот это я и обозвал комбайном. но! ведь в любой системе, особенно в винде бывают глюки, решаемые только перезагрузкой.. да и заражения тем же шифровальщиком еще никто не отменял. А теперь представьте такой всё-во-одном да на VDS да где то в паблик-ДТЦ да еще светит наружу всем что дефолтом не закрыто. Просто потому, что к такой компании не нашлось специалиста/денег/знаний как закрыть свои данные хотя бы минимально. Поэтому в варианте "сервер-в-облаке" - или постараться тщательно закрыть сервер (вариантов много, это отдельная тема, но сразу скажу: всему интернету НЕ НАДО СВЕТИТЬ ни RDP ни http-1c), если всё-в-одном - или (если хостинг позволяет) сделать там приватную сеть (вирт-микротик + серверы/сервисы). Не сильно дороже, но гораздо лучше защищены ваши данные. И масштабируемо.
Дальше рассказываю про "Сервер в офисе". Пришел к выводу, что лучше всё-таки разносить службы по разным "серверам". На базах больше 1-2-3Гб заметил, что 1С-server обращаясь по сети TCP/IP c SQL (для конкретики дальше буду PSQL использовать, но тесты показали, что и с MS SQL всё ровно так же) довольно ощутимо подтормаживает. Причем для эксперимента пробовал заменить GigaEth на оптику - и на 1 и на 10 и на 28Gbps ситуация не меняется, тормоза есть. При этом скорость простого копирования файлов (SMB, FTP, etc.) показывает, что скорость соединений реально сильно растет при смене сетевок и коммутаторов. Не спорю, это проблема точно ПО, скорее всего неоптимальности запросов (выбора нет, избавлять конф-ию от подобных проблем - дорогое удовольствие, а речь про small-business :); лечить подобные баги сама 1С тоже не желает, им не до этого, надо деньги зарабатывать) и/или специфики работы 1С с протоколом TCP. Возвращаясь к разнесению сервисов (в минималке RDP-1c-client, 1c-server, PSQL) на разные ОС (критична как раз связка 1c-server-PSQL) - опыты показали, что эти "серверы", живущие на одном железе но в разных виртуальных машинах вполне сносно общаются, тормозов "как раньше" нет.. ну или PSQL прямо на хосте, где поднята виртуалка с 1С-server'ом - тоже нормально. Вот как раз ниже и упоминали named pipe.
Определились примерно с топологией, выбираем железо. Вспоминаем, что денег мало - приходим к варианту Xeon+SuperMicro или i7-i9+хорошая_МВ и про второй вариант конкретнее (опять же из опыта): при установке памяти больше 16Гб на пользовательском железе Windows Server теряет стабильность. Тестировал на небольшом ассортименте MB&CPU, но в разные годы и разные версии ОС. Симптом простой: неожиданно винда колом встает до перезагрузки по питанию. Для любителей AMD/Intel Core iX - как вариант: использовать Linux KVM или Xen - на том же пользовательском железе вполне себе спокойно работает виртуализация в рамках которой уже виртуальная машина с Windows Server. Однако не всегда ИТ-специалист для решения вопросов малого бизнеса готов подъехать - т.ч. всё таки рекомендую собирать на SuperMicro - там есть IPMI и большинство проблем можно решить удаленно.
Итак, сервер "на минималках": собираем на Xeon+SuperMicro, ядра-потоки - по потребности (мало ли сколько ВМ панируете добавить), но не меньше 4 :); ГГц побольше, 1с их любит. Памяти побольше (пригодится для терминалки) и пошустрее. Диски: на зеркало(2*SSD) ставим ОС, на отдельном 1*SSD планируем хранить файлы вирт. машин, отдельно 1*NVMe для работы БД, 1*HDD/SSD_для_тестовых_баз и парочку SATA-HDD побольше для архивов (на зеркале!). Ставим ОС на железо (можно что привычнее, хоть винду; я для бедных предпочитаю Proxmox), создаем ВМ: 1С-server (сервер лицензий можно отдельно кому нравится), 1C-PSQL (диск для БД напрямую!), RDP-server для 1С-client, 1С-PSQL-Для-testDB (программисты постоянно плодят копии, достали уже). Настраиваем ночную архивацию самих ВМ, после настройки ПО - уже его архивацию - в .dt и pg_dump (тот же Effector Saver умеет на SFTP лить - вот прям на зеркало архивов). Доступы ко всему - маршрутизатором офиса
да, разнесение сервера 1С и сервера БД на разные железки приводит к задержкам. но в случае "несколько ВМ на одном железе" всё хорошо. программер пытался убедить, что в принципе можно делать только комбайн в рамках одной ОС потому что "как правильно" только он знает :) но потом понял что всё несколько сложнее и есть другие мнения и опыт
имелось в виду "Сервер 1С" и например PostgreSQL ... тесты показали, что даже на 10Гбит оптике есть ощутимые задержки (база в 40-50Гб), хотя при использовании в рамках 1 железки, например на разных ВМ - этих задержек нет. Как нет их и при использовании этого ПО в рамках 1 например физического сервера.
описанные API в этом плане от телеги отличаются только ценником >0
более стабильно использовать модем-в-сервере, но тоже упираемся в стабильность сети сотового оператора. да и никакие алерты не защитят если после работы "ответственный ушел в баню" Так что "мониторинг и наблюдение" наше всё
"В принципе есть люди, которые в состоянии совмещать роли" - реально? Вы их видели? ... мне как-то очень уважаемый мною программер рассказывал, что серверную часть низзя отделять от sql-ной "патамушто тормозить будет". правда потом осознал, даже извинился :)
Вы простите, но это бред. из НОРМАЛЬНЫХ программеров 1С не видел никого, кто может поднастроить postgresql, им тупо некогда этим заниматься. Впрочем как и обновлением платформ и активацией лицензий. Да им просто доступ такой никто не даст. И уж железо подобрать точно не смогут... слово "кластер" они тоже не знают. Что уж говорить - каждый первый программер тупо заливает всё на рабочий стол терминалки куда ему временно доступ дали и пофиг на место, на производительность диска который из-за нехватки этого места тормозить начинает (речь про простейший сервер "всё-в-одном")
Что в статье описано - это "всё по верхам, ни в чем конкретно не разбирается" ... как впрочем и 90% админов не лезут править код, что не мешает провести анализ ошибки
Ну так ВМ - вот только "по шаблону" проблематично", т.е. ранее созданный домен восстанавливать/дублировать из копии не стОит в той же сети :) да и всегда ли нужен он т.ч. всё равно много чего ручками делать и это уже совсем другая история
@Контейнер — это изолированный процесс, которому кажется, что он запущен в отдельной системе. Но на самом деле он использует ядро хостовой ОС @ да и жизненный цикл домена не подразумевает частое пересоздание.
так то винда - это ВМ-ки, а вот сиквел смотря какой... вполне себе можно и сиквел и 1С закрутить в контейнерах. ну и 1с-ку в браузере - тогда и терминальный не нужен. остается вопрос: зачем тут домен?
про LLM добавлю 5 копеек IMHO: чтобы нормальный результат получить - надо потратить время и нормально сформулировать. и всё равно потом перепроверка и отладка. Зачастую очень быстрее получается "сделать с каких-то СВОИХ готовых наработок копию и поменять что надо". В-общем ИИ вообще не впечатлил в том виде как сейчас
Оригинал - 30т.р. - надо 4шт - 120т.р. Совместимый ДОРОГОЙ 5000*4=20т.р. Разница в 100т.р. на 1 комплекте! В моей практике сейчас надо минимум 1 комплект / 1 месяц МФУ таких 20 штук. В год разница 12*20*100т.р.=24млн.руб - на 250чел. штата из практики: оригиналы только бюджетники могут себе позволить
HDD hotswap в аппаратном зеркале :) вытаскиваешь 1 и в сейф, ставишь чистый. отзеркалились - меняешь другой на чистый даже настраивать ничего не надо, периодичность по желанию
всё правильно сказали выше: дыра - в сливе. если банк хоть "не всем, а только нужным", то левое приложение - всем кто заплатит сольет. а зачем кому то знать - сколько у меня на счету и сколько проходит за месяц
кто-то пользуется одним банком? в марте кэшбеки в "1-ом банке одни, во 2-ом другие", в апреле частично наоборот... ибо а зачем терять даже ту копеечку, если она (например) в разы превышает затраты на сигареты и выпивку
считаю "приложение умеет подтягивать из банков" - плохой идеей. это ж очевидная дыра
я тоже в табличке веду, гибкость повыше чем у приложух... не хватит гибкости - можно свою написать. единственно считаю разбивать например продукты на "Мясо-конфеты" - уже маразм.. да и зачем мне помнить 3-го или 12-го числа купил продукты на 2т.р. ... в-общем не стоит сильно детализироваться - времени много тратится
поверьте, приятнее часы подождать и продолжить, чем потерять всё, когда (недо)оператор ДЦ ловит атаку... был прецедент пару лет назад (не скажу с кем), благо архивы сливали себе не доверяя оператору (а ведь многие даже денюжку берут за хранение архивов в ДЦ)
в случае с несколькими провайдерами также удобно делить трафик по типу... простейший пример (рассмотрим только внешний, без всяких SMB,mail,etc.): весь HTTP(s) трафик через ЦО (без всяких прокси) по каналу с шифрованием (чтобы ИБ посмотрели что там :) ), а вот видео трафик через резервного провайдера сразу в интернет (допустим у нас нет своего ВКС центра в периметре, подключаемся к чужим облачным) если в нем нет ничего секретного - сразу и шифрующие роутеры разгружаются и каналы. В-общем PBR вещь действительно удобная, но ведь реализована и документировано всё еще в начале века, если не в прошлом... ничего нового не увидел :)
Да какие претензии, объясню подробнее:
почему-то многие считают, что удобнее всё, что относится к 1С собрать в рамках одного сервера и одной ОС, Windows самом собой. вот это я и обозвал комбайном. но! ведь в любой системе, особенно в винде бывают глюки, решаемые только перезагрузкой.. да и заражения тем же шифровальщиком еще никто не отменял. А теперь представьте такой всё-во-одном да на VDS да где то в паблик-ДТЦ да еще светит наружу всем что дефолтом не закрыто. Просто потому, что к такой компании не нашлось специалиста/денег/знаний как закрыть свои данные хотя бы минимально.
Поэтому в варианте "сервер-в-облаке"
- или постараться тщательно закрыть сервер (вариантов много, это отдельная тема, но сразу скажу: всему интернету НЕ НАДО СВЕТИТЬ ни RDP ни http-1c), если всё-в-одном
- или (если хостинг позволяет) сделать там приватную сеть (вирт-микротик + серверы/сервисы). Не сильно дороже, но гораздо лучше защищены ваши данные. И масштабируемо.
Дальше рассказываю про "Сервер в офисе". Пришел к выводу, что лучше всё-таки разносить службы по разным "серверам". На базах больше 1-2-3Гб заметил, что 1С-server обращаясь по сети TCP/IP c SQL (для конкретики дальше буду PSQL использовать, но тесты показали, что и с MS SQL всё ровно так же) довольно ощутимо подтормаживает. Причем для эксперимента пробовал заменить GigaEth на оптику - и на 1 и на 10 и на 28Gbps ситуация не меняется, тормоза есть. При этом скорость простого копирования файлов (SMB, FTP, etc.) показывает, что скорость соединений реально сильно растет при смене сетевок и коммутаторов.
Не спорю, это проблема точно ПО, скорее всего неоптимальности запросов (выбора нет, избавлять конф-ию от подобных проблем - дорогое удовольствие, а речь про small-business :); лечить подобные баги сама 1С тоже не желает, им не до этого, надо деньги зарабатывать) и/или специфики работы 1С с протоколом TCP.
Возвращаясь к разнесению сервисов (в минималке RDP-1c-client, 1c-server, PSQL) на разные ОС (критична как раз связка 1c-server-PSQL) - опыты показали, что эти "серверы", живущие на одном железе но в разных виртуальных машинах вполне сносно общаются, тормозов "как раньше" нет.. ну или PSQL прямо на хосте, где поднята виртуалка с 1С-server'ом - тоже нормально. Вот как раз ниже и упоминали named pipe.
Определились примерно с топологией, выбираем железо. Вспоминаем, что денег мало - приходим к варианту Xeon+SuperMicro или i7-i9+хорошая_МВ и про второй вариант конкретнее (опять же из опыта): при установке памяти больше 16Гб на пользовательском железе Windows Server теряет стабильность. Тестировал на небольшом ассортименте MB&CPU, но в разные годы и разные версии ОС. Симптом простой: неожиданно винда колом встает до перезагрузки по питанию. Для любителей AMD/Intel Core iX - как вариант: использовать Linux KVM или Xen - на том же пользовательском железе вполне себе спокойно работает виртуализация в рамках которой уже виртуальная машина с Windows Server.
Однако не всегда ИТ-специалист для решения вопросов малого бизнеса готов подъехать - т.ч. всё таки рекомендую собирать на SuperMicro - там есть IPMI и большинство проблем можно решить удаленно.
Итак, сервер "на минималках": собираем на Xeon+SuperMicro, ядра-потоки - по потребности (мало ли сколько ВМ панируете добавить), но не меньше 4 :); ГГц побольше, 1с их любит. Памяти побольше (пригодится для терминалки) и пошустрее. Диски: на зеркало(2*SSD) ставим ОС, на отдельном 1*SSD планируем хранить файлы вирт. машин, отдельно 1*NVMe для работы БД, 1*HDD/SSD_для_тестовых_баз и парочку SATA-HDD побольше для архивов (на зеркале!). Ставим ОС на железо (можно что привычнее, хоть винду; я для бедных предпочитаю Proxmox), создаем ВМ: 1С-server (сервер лицензий можно отдельно кому нравится), 1C-PSQL (диск для БД напрямую!), RDP-server для 1С-client, 1С-PSQL-Для-testDB (программисты постоянно плодят копии, достали уже). Настраиваем ночную архивацию самих ВМ, после настройки ПО - уже его архивацию - в .dt и pg_dump (тот же Effector Saver умеет на SFTP лить - вот прям на зеркало архивов). Доступы ко всему - маршрутизатором офиса
да, разнесение сервера 1С и сервера БД на разные железки приводит к задержкам. но в случае "несколько ВМ на одном железе" всё хорошо.
программер пытался убедить, что в принципе можно делать только комбайн в рамках одной ОС потому что "как правильно" только он знает :) но потом понял что всё несколько сложнее и есть другие мнения и опыт
имелось в виду "Сервер 1С" и например PostgreSQL ... тесты показали, что даже на 10Гбит оптике есть ощутимые задержки (база в 40-50Гб), хотя при использовании в рамках 1 железки, например на разных ВМ - этих задержек нет. Как нет их и при использовании этого ПО в рамках 1 например физического сервера.
подтверждаю: МОЯ простейшая задача - дал описание, реализовано за 1 мин.... и "не работает". потом еще час потратил на отлов багов и неточностей
описанные API в этом плане от телеги отличаются только ценником >0
более стабильно использовать модем-в-сервере, но тоже упираемся в стабильность сети сотового оператора. да и никакие алерты не защитят если после работы "ответственный ушел в баню"
Так что "мониторинг и наблюдение" наше всё
"В принципе есть люди, которые в состоянии совмещать роли" - реально? Вы их видели? ... мне как-то очень уважаемый мною программер рассказывал, что серверную часть низзя отделять от sql-ной "патамушто тормозить будет". правда потом осознал, даже извинился :)
Вы простите, но это бред.
из НОРМАЛЬНЫХ программеров 1С не видел никого, кто может поднастроить postgresql, им тупо некогда этим заниматься. Впрочем как и обновлением платформ и активацией лицензий. Да им просто доступ такой никто не даст. И уж железо подобрать точно не смогут... слово "кластер" они тоже не знают. Что уж говорить - каждый первый программер тупо заливает всё на рабочий стол терминалки куда ему временно доступ дали и пофиг на место, на производительность диска который из-за нехватки этого места тормозить начинает (речь про простейший сервер "всё-в-одном")
Что в статье описано - это "всё по верхам, ни в чем конкретно не разбирается" ... как впрочем и 90% админов не лезут править код, что не мешает провести анализ ошибки
Ну так ВМ - вот только "по шаблону" проблематично", т.е. ранее созданный домен восстанавливать/дублировать из копии не стОит в той же сети :) да и всегда ли нужен он
т.ч. всё равно много чего ручками делать и это уже совсем другая история
@Контейнер — это изолированный процесс, которому кажется, что он запущен в отдельной системе. Но на самом деле он использует ядро хостовой ОС @
да и жизненный цикл домена не подразумевает частое пересоздание.
так то винда - это ВМ-ки, а вот сиквел смотря какой... вполне себе можно и сиквел и 1С закрутить в контейнерах. ну и 1с-ку в браузере - тогда и терминальный не нужен. остается вопрос: зачем тут домен?
про LLM добавлю 5 копеек IMHO: чтобы нормальный результат получить - надо потратить время и нормально сформулировать. и всё равно потом перепроверка и отладка. Зачастую очень быстрее получается "сделать с каких-то СВОИХ готовых наработок копию и поменять что надо". В-общем ИИ вообще не впечатлил в том виде как сейчас
Оригинал - 30т.р. - надо 4шт - 120т.р.
Совместимый ДОРОГОЙ 5000*4=20т.р.
Разница в 100т.р. на 1 комплекте! В моей практике сейчас надо минимум 1 комплект / 1 месяц
МФУ таких 20 штук. В год разница 12*20*100т.р.=24млн.руб - на 250чел. штата
из практики: оригиналы только бюджетники могут себе позволить
HDD hotswap в аппаратном зеркале :) вытаскиваешь 1 и в сейф, ставишь чистый. отзеркалились - меняешь другой на чистый
даже настраивать ничего не надо, периодичность по желанию
:)