MikeDDС единой БД для всех аптек вы сразу столкнетесь с проблемой связи: аптека будет вынуждена простаивать если связи с центральной БД не будет.

Связь обычно наименьшая из проблем. При нормальной архитектуре (минимуме синхронных round-trip запросов), просто переключаетесь на 3г и проблема решена. К примеру у нас хватает сетей с фронтами в одной базе, кто в онлайн режиме работает.

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

Ну, а что касается 1С, если у вас активно используются автоматические блокировки, то лучше сразу не пробовать. С управляемыми зависит от того кто писал дорабатывал. Хотя все равно мне было бы стремно.

Программист 1сМожно и онлайн. У меня больше пользователей - все работает.

Но я бы сделал с допустим задержкой 10 минутной. Тоесть распределенная база. Раз в 10 минут обмен. Если рушится центральная база или нет связи - все работает на периферии. А закрывать аптеку из-за того что нет связи... глупо.

Да и настраивать 1с в этом случае легче (принтеры и тд)

С репликацией геморроя куда больше, особенно с встречной (конечно если у вас не система пришло \ ушло осталось). Во-первых ее надо реализовывать. Во-вторых с ограничениями - беда, непонятно что делать если в одной базе повесили ограничение, а из другой пришли данные которые его нарушают. В третьих надо дофига серверов - а) покупать самому, б) админить. Куда проще и дешевле резервный канал организовать.

Благо сейчас облака все такое, заказчики куда охотнее соглашаются на одну базу. Как вспомню распределенки и их поддержку - аж в дрожь бросает (хотя еще до сих пор таких клиентов вагон на поддержке :( )

Программист 1сМожно и онлайн. У меня больше пользователей - все работает.

А кстати интересно как? Я правильно понимаю, что у вас явно MS SQL в режиме версионника с управляемыми блокировками?

Просто я все никак не могу понять, как можно на СЛОЖНОЙ системе ВРУЧНУЮ оценить все возможные варианты конкурентного доступа и правильно синхронизировать их. Потому как даже с Write-Write блокировками достаточно проблем, а с Read-Write... Два варианта а) если слишком большие блокировки - аааа... у всех все висит, б) если слишком маленькие - а че у меня тут суммы не сходятся...

MikeDDNitro_JunkieВ третьих надо дофига серверов - а) покупать самому, б) админить. Куда проще и дешевле резервный канал организовать.
Кучеряво живете. А у нас на обслуге есть аптечные пункты с 1 компом, выполняющем функции сервера БД и кассы, причем с процом типа старого атома. И единственный канал связи - 3г модем. Аптеки сейчас не настолько рентабельный бизнес чтобы на каждую точку держать резервный канал.

Ну резервный канал по возможности. В любом случае админить такие аптечный пункты себе дороже. Ляснется веник, вы пока до нее доедете, пока все заново настроите, простой будет больше чем при падении связи. Я уж молчу про случаи, когда у вас изменения в системе (например в программе лояльности) идут очень часто, и нужны постоянные обновления. Плюс может еще просто место закончится, вирусы и т.п. А уж когда какая-нибудь деноминация, тогда вообще вешаться можно...

А так просто связь настроили (а она все равно для банковских карточек, системы лояльности да и просто обмена документами нужна) и все. Да и 3г по опыту падает куда реже чем проводная связь - экскаватору тяжелее ее перерезать :)

mad_nazgulMironico,

Ну... Я сейчас не в курсе последних веяний 1C, но раньше такая задача решалась ч/з MS Terminal Server.
Опять же тут проблема будет в качестве связи.

Тут основная проблема даже не в связи, а в стыке с оборудованием. В RDP те же COM-порты через пень-колоду работают. Плюс нужная еще терминальная ферма, опять-таки с администрированием. Ну и к ширине пропускного канала требования существенно больше, чем при нормальной трехзвенке. То есть может быть еще хуже чем обычные распределенки.

MironicoЯ вот так и думал что держать повсюду по 2 инета:
1. Основной (если есть то проводной)
2. 3g для переключения если падает 1й.

В офисе тоже 2 канала уже есть.

В business-critical процессах лучше вообще хостить во внешних датацентрах, где электричество, связь по несколько раз задублировано и уборщицы с админами обученные. Только лучше приличный выбирать хотя бы по Tier III ( https://habrahabr.ru/company/ua-hosting/blog/243109/)

Сисой1. Использовать внешний дата-центр с хорошей репутацией.
2. Использовать web-доступ. Соответственно и приложение должно быть на тонком клиенте, с асинхронными вызовами и управляемыми блокировками.
3. Иметь в штате (или на аутсорсе) хорошего 1С:Эксперта по технологическим вопросам.
4. Иметь резервные каналы связи (3/4g).

Основной минус: для работы в тонком/web клиенте нужно современное оборудование клиентских станций. Как минимум, AMDx4/2 и хотя бы 19" широкоэкранный монитор. Всякую хрень типа Pentium IV с квадратными 17" - на помойку.

С первыми 4 пунктами в целом согласен. Но веб-доступ не прокатит из-за стыка с оборудованием.

Ну и с клиентскими станциями конечно у 1Са засада, у меня на demo.1c.ru их веб на 4-х ядернеке 3,5GHz и 16 гб памяти просто хождение по форме с именем товара и группой секунду занимает (причем там 2 round-trip'а, но они всего 200мс, остальное scripting \ rendering).

СисойNitro_JunkieС первыми 4 пунктами в целом согласен. Но веб-доступ не прокатит из-за стыка с оборудованием.


Согласен. Там, где оборудование - тонкий клиент через VPN.

Ну VPN не факт что обязателен. Можно и просто через интернет работать. Правда тогда у пользователей будет интернет :). Ну и так небезопаснее, но если поставить какой-нить centos, то шансы подцепить вирус не такие и уж большие (быстрее пользователь троян словит). Во всяком случае у нас есть несколько клиентов, которые так работают.