[Цибир]

Здравствуйте.
Есть пользователи (100 штук), работающие с одной БД 1С (файловый вариант). Часть пользователей (50 штук) сослали в другой город (в Воркуту), но им нужно работать все с той же БД.
Когда пользователи находились в одном здании, то был один сервер 1С, который находился в том же здании.
Теперь, когда часть пользователей депортировано, то возник вопрос, как обеспечить бесперебойную работу всех пользователей..
1. Переводим на клиент-серверный вариант работы
2. Можно развернуть отказоустойчивый кластер
Как я понимаю, кластер – штука полезная, но не поможет, если отвалится канал между нами и Воркутой. Пользователи с Воркуты не смогут работать совсем. Соответственно, если бы было две базы (SQL) данные в которых бы синхронизировались, то одна была бы у нас, а вторая – в Воркуте. То есть, если канал отвалился, то местные пользователи обращаются к своей БД, а Воркута - к своей. Когда канал восстановлен – данные синхронизируются, у всех все одинаково, то есть, все хорошо. Но тут возникает вопрос потери данных (вдруг и местные, и Воркута изменяли одни и те же данные). Вообще, нормально ли для 1с, что две бд будут синхронизироваться.
Посоветуйте, пожалуйста, как лучше организовать схему серверов. Наверняка, не мы первые с этим сталкиваемся. Веб-сервер нам не очень хочется рассматривать почему-то.

[Vofka]

Распределенные базы данных - это обычное дело. Но в таком случае возникают определенные сложности на разработку и поддержку такой системы.

Но тут возникает вопрос потери данных (вдруг и местные, и Воркута изменяли одни и те же данные)

Этот вопрос сперва нужно решить не на техническом уровне, а на административном. Решений может быть 2:
1) У какой-то базы есть приоритет по изменению данных, назовем её центральная база. Обмен сделать таким образом, чтобы данные сперва выгружались из центральной базы, потом загружались во "вторую", потом со второй выгружались и загружались в центральную. При этом все понимают, что если данные менялись в двух базах, то данные второй базы будут переписаны.
2) Разделить административно и технически возможность менять одни и те же данные в двух базах одновременно. Например, контрагентов поставщиков редактируют только в центральной базе, а контрагентов покупателей только во второй. Тогда теоретически просто не возникнет ситуации, что данные одновременно менялись в двух местах.

Сообщение отредактировал Vofka - 13.01.16, 10:51

[Цибир]

Спасибо. Но че-та не радует перспектива)

[Petre]

Механизм отказоустойчивого кластера сервера 1с никак не поможет при потере связи с сервером бд.

[Acid]

Спасибо. Но че-та не радует перспектива)

Работайте через RDP

[Vofka]

Цибир, у вас есть 2 варианта решения вопроса:
1) Работать в одной базе. При этом часть пользователей будут работать, например, через RDP или VPN. В этом случае вам нужно решить вопрос с более-менее стабильным интернетом там и принять риски, что если интернет там отвалится, то 1С-а там не будет. Минус в том, что доступность 1С будет зависеть от интернета. Плюс в том, что организовать технически это не сложно.
2) Делать распределенную базу. Минус в сложностях технической реализации и дальнейшей поддержке. Плюс в том, что у всех всегда 1С работает.