Использование храна: сервер хранилища vs шара


#1

Доброго.
Какая разница в стабильности/производительности в работе с храном между вариантами:

  1. Все разработчики работают с храном только через шару;
  2. Все разработчики работают с храном только через сервер-хранилища;
  3. Разработчики работают с храном кто через сервер-хранилища, кто через шару
    ?

#2

Второй вариант (все через сервер) - ок.
Остальные - отказать из-за риска поломки хранилища, например, если кто-то подключится с неправильной версией платформы.


#3

2 правилен и единственный рабочий при нескольких разработчиках.
1 и 3 пробовали, не работает.
Будут постоянные проблемы с доступом разных пользователей.
Дело в том, что в 8.3 создаются отдельные файлы на элементы хранилища и этим файлам выдаются права от имени создателя, права от каталога хранилища почему-то не всегда выдаются.
В итоге один разраб помещает свои новые объекты в хранилище, у него коммит в хранилище проходит,
далее 2-й разраб захватывает эти новые объекты, меняет в 1С, но коммит не проходит,
т.к. выдается ошибка системы проо доступы.

При работе с хранилищем через сервер этих проблем, т.к. все изменения попадают от одного системного пользователя, под которым стартует сервер хранилища.


#4

У нас работа ведется по варианту 3. Проблем замечено не было.

Сама 1С говорит, что без разницы как подключаться:

В общем случае система «1С:Предприятие» обеспечивает одновременную работу с хранилищем конфигурации с использованием всех протоколов доступа к хранилищу: файловый доступ, протокол TCP и протокол HTTP.

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


#5

Какие-то неленивые у вас админы - раз права устанавливают поименно.

Куда проще - назначил доступ на шаре группе пользователей, дал вам права на изменение группы, поставил оснастку AD. И больше не отвлекаешься на всякую ерунду. Максимум, изменить состав группы самостоятельно раз в полгода, когда отвественный 1С-ник в отпуске.


#6

“Чистых” вариантов доступа всего 2:

  1. Файловый
  2. Сервер хранилища

Есть возможность организовать дополнительный транспорт через HTTP (еще 2 “серых” доступа):
3. HTTP с подключением к файлам
4. HTTP с подключением к серверу

Остальное - комбинации в том или ином виде этих четырех видов.

Затем начинаются ньюансы:
п. 1 есть возможность разграничить права доступа к хранилищам.
п. 2 обеспечивает максимальную согласованность доступа к хранилищам. С правами печаль - кто угодно может подключаться к серверу и создавать новые хранилища. Хорошо, что еще удалять хранилища через сервер нельзя.

п. 1 позволяет переместить уже неиспользуемое хранилище в архив
п. 2 сервер хранилища “держит” файлы. Убрать неиспользуемое хранилище можно только остановив сервер. Зато проще организовывать обслуживание хранилищ - достаточно остановить сервер.

п.1 дает возможность подключаться к хранищу с разными версиями платформы (естественно по очереди).
п.2 только одна версия платформы. разработка когда тестовый контур уже на новой платформе, а рабочий контур на старой возможна только с костылями.


#7

a с gitsync как? ему же файловый доступ к храну нужен


#8

Гитсинку доступ на чтение нужен, никаких проблем с ним не выявлено.


#9

Юрий, а можно вопрос касаемо третьего пункта?
Пример конфигов подключения.


#10

Хм, поднял по документации - такого варианта нет. Прошу прощения, что ввел в заблуждение. п.3 отменяется


#11

Спасибо.
Эх, а счастье было так близко :frowning: