Будет реализовано за счет угрозы потери данных, что очень рискованное решение на мой взгляд. По опыту перетаскивание файловой БД с HDD на SSD, потом на NVMe очень не надолго дает отсрочку от принятия решения к переезду на SQL. Полгода-год. Мое мнение, что овчинка не стоит выделки надо решать проблему радикально.
Если мне память не изменяет, то 1Совские блокировки и так хранятся в памяти соответствующего менеджера кластера.
Интересно, какой там размер самой тяжелой базы, что нельзя было спокойно перетащить полный дамп БД, а потом в технологическое окно накатить дифференциальную копию?
>снижает нагрузку на сервер приложений 1С, который часто бывает перегружен Чаще чем сервер СУБД? Перегружен в каком плане, какие ресурсы?
>в процессе выяснилось, что у заказчика была неверная конфигурация SQL-сервера >на практике конфигурации пришлось дополнительно настраивать для увеличения производительности дисков. Почему это выяснилось уже в процессе миграции, а не до? Что за интересный такой кейс? Можно подробнее рассказать?
Как переносили лицензии? При тестовой миграции по сути нужен двойной набор лицензий, как решали этот вопрос?
Конечно bare metal. Процентов на 10%. Можно еще 1С кластер и СУБД не разносить и поставить на одной физической машине -- за счет shared memory еще процентов 10-20% можно будет выиграть. Только вот при резком росте нагрузки это не поможет. А вот управляемость, стоимость эксплуатации, отказоустойчивость, скорость восстановления и прочее, прочее сильно пострадают.
На мой взгляд лучше использовать виртуалки и при кратном росте нагрузок увеличивать их ресурсы и/или думать как масштабировать систему чтобы пережить пик.
А зачем? Если только файловая БД, но это история не про средние и большие нагрузки. В клиент-серверном варианте и так оперативные данные БД в оперативке в кэше.
Что у 1С (не СУБД) требовательно к I/O я вот так сходу даже придумать не могу. Сеансовые данные разве что, но они и так мапятся в RAM.
Еще стоит отметить, что под каждую версию платформы придется поднимать отдельный экземпляр сервера 1С на сервер лицензирования соответствующей версии. Если у вас зоопарк платформ, то 4Gb RAM далеко не факт что хватит.
О том где размещать серверные лицензии вопрос дискуссионный. 1С рекомендует непосредственно на машине где запущен сервер. Т.к. с сервиса лицензирования лицензию может утащить любой, то могут быть неприятные ситуации. Но тут все индивидуально конечно.
Если есть куда упрощать, то значит она не простая. Что она сложнее жизни других разработчиков никто вроде не говорил, но согласитесь, что на мероприятии для разработчиков 1С было бы странно упрощать жизнь разработчикам не 1С. Полагаю всегда могут найтись разработчики 1С которые хотят упростить себе жизнь. Например я. Нет.
Если вам нужны условные частные сети в государственных целях, то со всеми необходимыми руководствами сможете ознакомиться в секретной части при условии, что у вас есть соответствующий доступ конечно же.
Поддержу. С франчи рулетка какая-то. То нормальный код, местами даже классный, то спагетти-код приправленный вышеописанными ужасами вроде запросов в цикле. При том это может встречаться в рамках одной задачи.
Я так и не понял что такого натворили пользователи, что все дружно должны страдать. Напомните пожалуйста в чьих интересах вроде как должен действовать контроль за финансово-кредитными организациями со стороны ЦБ РФ?
Хотел оценить разнообразие и наличие нужных мне приложений (или аналогов). Но на сайте не нашел такой возможности. Устанавливать приложение только ради этого я конечно же не буду.
Интересно там есть требование подписывать эти письма ЭЦП банка? Их кто-нибудь проверят? А то вдруг можно свои ВПНы под шумок в белый списочек пропихнуть.
Будет реализовано за счет угрозы потери данных, что очень рискованное решение на мой взгляд. По опыту перетаскивание файловой БД с HDD на SSD, потом на NVMe очень не надолго дает отсрочку от принятия решения к переезду на SQL. Полгода-год. Мое мнение, что овчинка не стоит выделки надо решать проблему радикально.
Если мне память не изменяет, то 1Совские блокировки и так хранятся в памяти соответствующего менеджера кластера.
Интересно, какой там размер самой тяжелой базы, что нельзя было спокойно перетащить полный дамп БД, а потом в технологическое окно накатить дифференциальную копию?
>снижает нагрузку на сервер приложений 1С, который часто бывает перегружен
Чаще чем сервер СУБД? Перегружен в каком плане, какие ресурсы?
>в процессе выяснилось, что у заказчика была неверная конфигурация SQL-сервера
>на практике конфигурации пришлось дополнительно настраивать для увеличения производительности дисков.
Почему это выяснилось уже в процессе миграции, а не до? Что за интересный такой кейс? Можно подробнее рассказать?
Как переносили лицензии? При тестовой миграции по сути нужен двойной набор лицензий, как решали этот вопрос?
Конечно bare metal. Процентов на 10%. Можно еще 1С кластер и СУБД не разносить и поставить на одной физической машине -- за счет shared memory еще процентов 10-20% можно будет выиграть. Только вот при резком росте нагрузки это не поможет. А вот управляемость, стоимость эксплуатации, отказоустойчивость, скорость восстановления и прочее, прочее сильно пострадают.
На мой взгляд лучше использовать виртуалки и при кратном росте нагрузок увеличивать их ресурсы и/или думать как масштабировать систему чтобы пережить пик.
А зачем? Если только файловая БД, но это история не про средние и большие нагрузки. В клиент-серверном варианте и так оперативные данные БД в оперативке в кэше.
Что у 1С (не СУБД) требовательно к I/O я вот так сходу даже придумать не могу. Сеансовые данные разве что, но они и так мапятся в RAM.
Еще стоит отметить, что под каждую версию платформы придется поднимать отдельный экземпляр сервера 1С на сервер лицензирования соответствующей версии. Если у вас зоопарк платформ, то 4Gb RAM далеко не факт что хватит.
О том где размещать серверные лицензии вопрос дискуссионный. 1С рекомендует непосредственно на машине где запущен сервер. Т.к. с сервиса лицензирования лицензию может утащить любой, то могут быть неприятные ситуации. Но тут все индивидуально конечно.
Сегодня как раз читал статью по этой теме. Ссылку оставлять не буду, но гуглится по "Фабрика накруток. Как vk превращает рунет в телевизор"
Писать на почту на яндексе и выразить желание взломать государство? Дайте подумать...
Если есть куда упрощать, то значит она не простая. Что она сложнее жизни других разработчиков никто вроде не говорил, но согласитесь, что на мероприятии для разработчиков 1С было бы странно упрощать жизнь разработчикам не 1С. Полагаю всегда могут найтись разработчики 1С которые хотят упростить себе жизнь. Например я. Нет.
Если вам нужны условные частные сети в государственных целях, то со всеми необходимыми руководствами сможете ознакомиться в секретной части при условии, что у вас есть соответствующий доступ конечно же.
Поддержу. С франчи рулетка какая-то. То нормальный код, местами даже классный, то спагетти-код приправленный вышеописанными ужасами вроде запросов в цикле. При том это может встречаться в рамках одной задачи.
Я так и не понял что такого натворили пользователи, что все дружно должны страдать. Напомните пожалуйста в чьих интересах вроде как должен действовать контроль за финансово-кредитными организациями со стороны ЦБ РФ?
Загляните в расчет себестоимости при закрытии месяца в типовой бухгалтерии например.
>"обязан проводить ее [авторизацию] в отношении пользователей, находящихся на территории Российской Федерации, одним из следующих способов:"
и далее ЗАКРЫТЫЙ список доступных способов.
Нет, там как раз прямо запрещаются способы кроме перечисленных.
Автор чуть менее года назад в своей первой публикации на хабре доказывал ровно тоже самое. А теперь вон оно как.
Хотел оценить разнообразие и наличие нужных мне приложений (или аналогов). Но на сайте не нашел такой возможности. Устанавливать приложение только ради этого я конечно же не буду.
Интересно там есть требование подписывать эти письма ЭЦП банка? Их кто-нибудь проверят? А то вдруг можно свои ВПНы под шумок в белый списочек пропихнуть.