CommuniGate Pro: Довідник

Наша взаимовыгодная связь https://banwar.org/

версія 6.2

Сервер CommuniGate Pro включає в себе Менеджер Довідника, в якому реалізований високопродуктивний, що грунтується на публічних стандартах Довідник.

Довідник може містити записи про Користувачів, домен і інших об'єктах CommuniGate Pro. Він також може містити в собі будь-які інші типи записів і може використовуватися як виділений сервер Довідника, обслуговуючий додатки, що працюють по протоколу LDAP.

Менеджер Довідника не є LDAP сервером. модуль LDAP CommuniGate Pro забезпечує доступ до Довідника для LDAP клієнтів, але різні компоненти CommuniGate Pro (Менеджер користувачів і Менеджер доменів, Веб інтерфейс користувача і т.д.) отримують дані з Довідника безпосередньо, минаючи LDAP протокол.

У Менеджері Довідника реалізований Мета-Довідник: такий Мета-Довідник може зберігати дані довідника в одному або декількох наборах серверних файлів (Локальні Тома), а також може використовувати зовнішні LDAP сервера як Віддалені Тома Довідника. Можливо безліч різних конфігурацій. Наступна найпростіша конфігурація є найбільш поширеною:

Всі дані Довідника зберігаються в одному Локальному Томе. В цьому випадку Мета-Довідник є таким же Довідником, який реалізується за допомогою звичайного LDAP сервера.
Всі дані Довідника зберігаються в одному віддаленого Томе. В цьому випадку Мета-Довідник використовується просто як метод доступу до записів, що зберігаються на зовнішньому LDAP сервері.

атрибут ім'я (ім'я атрибута) і одне або кілька значень атрибута.
Зазвичай атрибути представлені в формі ім'я = значення.
Імена атрибутів незалежні від регістру.
Приклади: userName = john
eyeColor = blue клас об'єкта атрибут з ім'ям objectClass; цей атрибут використовується для вказівки природи об'єкта, якому він належить.
Приклади: objectClass = person
objectClass = organization Повне ім'я записи (DN). послідовність атрибутів в формі ім'я = значення і розділених знаком коми (,).
DNи використовуються як унікальні імена об'єктів (записів).
Приклад: userName = john, server = BigIron, realm = Internet
DNи використовуються для побудови дерев імен об'єктів, де самий правий атрибут задає саме загальне ім'я, а самий лівий атрибут задає унікальне ім'я об'єкта.
Самий лівий атрибут називається Відносним Повним Іменем (RDN) - воно забезпечує унікальність імені об'єкта серед всіх інших об'єктів, що мають такий же батьківський DN.
Приклад: userName = jim, server = BigIron, realm = Internet
це інший DN, хоча "батьківський DN" точно такий же (server = BigIron, realm = Internet)
Приклад: userName = john, server = SmallCopper, realm = Internet
це інший DN, з іншим "батьківським DN" (server = SmallCopper, realm = Internet) запис довідника або об'єкт набір атрибутів з повним ім'ям записи
Зазвичай запис представляється у вигляді декількох рядків, що починаються з імені, представляє DN записи, за яким слідують атрибути запису. Записи зазвичай поділяються символом нового рядка.
Приклад: DN: userName = jim, server = BigIron, realm = Internet
objectClass = person
eyeColor = blue
mailboxLimit = 1024000
DN: userName = john, server = BigIron, realm = Internet
objectClass = person
eyeColor = green
mailboxLimit = 2048000
Зверніть увагу: стандарти LDAP рекомендують включати атрибут RDN в набір атрибутів, що становлять запис довідника. Менеджер Довідника CommuniGate Pro жорстко слідує цьому правилу. довідник набір записів довідника; може досягати дуже великих розмірів (мільйони записів). Через DN набір організується у вигляді дерева. При видаленні батьківського DN записи видаляються автоматично. При зміні (перейменування) батьківських DNов записи також автоматично змінюються. схема довідника набір обмежень довідника, що включають в себе:

набір імен атрибутів, які можуть використовуватися в Довіднику (userName, mail, city, eyeColor, ...);
набір значень атрибута objectClass, які можуть перебувати в Довіднику (person, organization, device, printer ...);
для кожного objectClass - імена атрибутів, які зобов'язана мати запис об'єкта; для записів типу objectClass = person схема може вимагати наявності атрибутів з іменами cn (Ім'я-Ідентифікатор) і sn (прізвище);
для кожного objectClass - імена атрибутів, які може мати запис об'єкта; для записів типу objectClass = person схема може дозволяти атрибути з іменами driverLicense і eyeColor.

Хоча весь Довідник CommuniGate Pro представляється клієнтам як одне велике дерево записів, його піддерева можуть зберігатися в окремих томах зберігання. Такий тип "віртуальних" довідників часто називають Мета-Довідником.

Довідник CommuniGate Pro підтримує два типи томів зберігання:

локальні - набори файлів, керовані Менеджером Довідника CommuniGate Pro. Ці файли містять записи довідника, інформацію про дублювання та схеми піддерев.
віддалені - дескриптори, які обслуговуються LDAP Менеджером Довідника CommuniGate Pro. Ці дескриптори містять інформацію про віддалених довідниках, доступ до яких здійснюється через LDAP.

В результаті Довідник CommuniGate Pro може мати піддерева, розташовані на віддалених серверах. Якщо LDAP сервер ldap.server.dom забезпечує доступ до будь-якого дереву довідника, то ви можете створити вказує на сервер ldap.server.dom віддалений тому в Довіднику CommuniGate Pro і, таким чином, повне дерево довідника ldap.server.dom (або одне з його піддерев) буде видно в Довіднику CommuniGate Pro як якесь поддерево.

Спочатку сервер CommuniGate Pro створює один Локальний Том Зберігання Main, в якому міститься весь довідник. Через Веб Інтерфейс Адміністратора ви можете додавати новий томи зберігання.

На діаграмі нижче показаний довідник, якій зберігається в одному Локальному Томе з ім'ям Main: На діаграмі нижче показаний той же довідник, але тепер він зберігається в двох Томах Зберігання, причому все поддерево o = MyCompany зберігається в окремому Томе Зберігання LDAP1: Приклад 1: Зовнішній LDAP сервер ldap1.com має поддерево o = MyCompany і ви хочете, щоб все Домени CommuniGate Pro і записи про Користувачів зберігалися в цьому поддереве. Використовуйте наступні налаштування:

В налаштуваннях центрального Довідника вкажіть Базовий DN як o = MyCompany, o = ldap1
Створіть Віддалений Том MYLDAP для поддерева o = ldap1.
Введіть ldap1.com як ім'я сервера і введіть в Настройках Тома MYLDAP в значенні Піддерево на Сервері порожній рядок.

Тепер, коли Сервер CommuniGate Pro спробує отримати доступ до запису довідника для користувача john в домені domain1.com:

Формується DN uid = john, cn = domain1.com, o = MyCompany, o = ldap1.
Менеджер Довідника визначає, що цей запис повинен розташовуватися в Томе MYLDAP і просить цей Том виконати необхідну операцію із записом, що має DN uid = john, cn = domain1.com, o = MyCompany (при цьому "зв'язує вузол" Тома o = ldap1 видаляється з DN).
Том MYLDAP відправляє запит з DN uid = john, cn = domain1.com, o = MyCompany на віддалений сервер ldap1.com.

Приклад 2: Зовнішній LDAP сервер ldap1.com має поддерево o = MyCompany і ви хочете, щоб все Домени CommuniGate Pro і записи про Користувачів зберігалися в цьому поддереве (точно також, як і в прикладі 1). Використовуйте наступні налаштування:

В налаштуваннях центрального Довідника вкажіть Базовий DN як o = ldap1
Створіть Віддалений Том MYLDAP для поддерева o = ldap1.
Введіть ldap1.com як ім'я сервера і введіть в Настройках Тома MYLDAP в значенні Піддерево на Сервері o = MyCompany.

Тепер, коли Сервер CommuniGate Pro спробує отримати доступ до запису довідника для користувача john в домені domain1.com:

Формується DN uid = john, cn = domain1.com, o = ldap1.
Менеджер Довідника визначає, що цей запис повинен розташовуватися в Томе MYLDAP і просить цей Том виконати необхідну операцію із записом, що має DN uid = john, cn = domain1.com (при цьому "зв'язує вузол" Тома o = ldap1 видаляється з DN).
Том MYLDAP додає до DN вказаний суфікс Піддерево на Сервері o = MyCompany і потім відправляє запит з таким DN uid = john, cn = domain1.com, o = MyCompany на віддалений сервер ldap1.com.

Відкрийте Веб Інтерфейс Адміністратора Сервера CommuniGate Pro і перейдіть за посиланням Довідник. Відкриються сторінки (розділ) з томами Зберігання Довідника. Для відкриття цих сторінок вам необхідно мати Права Доступу до Довідника.

Рядок <root> використовується для вказівки імені Тома Зберігання за замовчуванням (тобто Тома Зберігання, що зберігає корінь Дерева Довідника).

Для того, щоб створити новий Том Зберігання, введіть його ім'я (це ім'я буде використовуватися тільки для цілей адміністрування), Повний Ім'я (DN) для поддерева, яке повинно зберігається в цьому томі і натисніть на кнопку Створити Локальний Том або Створити Віддалений Том.

Локальні Тома Довідника - це набори файлів, що містять дані довідника (записи / пункти), схему томи, установки томи і журнал змін довідника.

Відкрийте через Веб Інтерфейс Адміністратора область Довідник і натисніть на посилання з ім'ям Локального Тома Зберігання. Відкриється сторінка з Установками Тома.

Рівень Журналу Використовуйте цей параметр, щоб вказати, яку інформацію Менеджер Локальних Томів Зберігання повинен зберігати в Журналі роботи Сервера. Перевіряти Схему Коли обрана ця опція, Менеджер Локального Тома Зберігання порівнює структуру всіх нових і змінюваних записів зі Схемою Тома. Якщо ця опція вимкнена, то Менеджер дивиться тільки імена атрибутів записів і перевіряє, що ці атрибути включені в схему Тома, але не перевіряє обмеження для objectClass. Обмеження Результатів Пошуку Ця настройка обмежує максимальне число записів, яке може повертати операція Пошуку в Довіднику. Створювати 'displayName' атрибут Якщо вказана ця опція, то Менеджер Локального Тома Зберігання перевіряє, чи був атрибут displayName явно затребуваний в операції пошуку, але при цьому сам цей атрибут відсутній в отриманої записи Довідника. В цьому випадку Менеджер створює атрибут displayName на льоту, використовуючи атрибут cn або, якщо він відсутній, атрибут uid.

Кожен Локальний Том має свою власну Схему. Додаткову інформацію про Схемах Тома дивіться в розділі схема .

Ви можете переглядати і змінювати Схему Локального Тома запитуючи і змінюючи віртуальну запис з DN cn = schema. Якщо Локальний Том змонтований на будь-якому поддереве Довідника, то DN записи для Схеми Тома буде cn = schema, поддерево.

Відкрийте Веб Інтерфейс Адміністратора і в розділі Довідник натисніть на засланні з ім'ям Видаленого Тома Зберігання для того, щоб відкрити сторінку з його Установками:

Рівень Журналу Використовуйте цей параметр, щоб вказати, яку інформацію Менеджер віддаленого Томів Зберігання повинен зберігати в Журналі роботи Сервера. Ім'я LDAP Сервера Це поле вказує ім'я або IP адреса віддаленого LDAP сервера, на якому розміщено поддерево Тома Зберігання. Якщо віддалений LDAP сервер використовує нестандартний TCP порт, то можна вказати Ім'я Сервера у вигляді імясервера: порт. Безпека Якщо встановлена опція TLSPort, то з'єднання з віддаленим сервером будуть встановлюватися в безпечному режимі. За замовчуванням портом для безпечних з'єднань є порт номер 636.
Якщо встановлена опція STARTTLS, то з'єднання встановлюються через звичайний порт LDAP, а потім вирушає LDAP команда STARTTLS для ініціювання комунікацій в безпечному (зашифрованому) режимі. Піддерево на Сервері Це поле вказує поддерево на віддаленому LDAP сервері, яке повинно бути "змонтовано". Якщо ця настройка має пусте значення, то весь віддалений довідник буде видно як поддерево Довідника CommuniGate Pro. Bind DN, Bind Пароль Це поле задає Повне ім'я запису і Пароль, які будуть використовуватися для "прив'язки" віддаленого LDAP сервера (для входу на нього). Якщо залишити це поле пустим, то CommuniGate Pro буде використовувати анонімний доступ до віддаленого LDAP сервера. Фільтр для пошуку Це поле може містити рядок з фільтром пошуку (в форматі RFC 2254). Цей фільтр додається в усі запити LDAP пошуку, які відправляються на LDAP сервер. Версія Протоколу Використовуйте це поле для вказівки підтримуваної віддаленим LDAP сервером версії протоколу LDAP. Кеш Каналів Використовуйте це поле для вказівки числа "Кешована" TCP сполук, що використовуються для з'єднання з віддаленим LDAP сервером.

У певних ситуаціях сервер CommuniGate Pro не повинен зберігати ніяких даних Довідника в своїх локальних Томах. Замість цього всі записи Довідника повинні зберігається на віддаленому LDAP сервері (якомусь іншому сервері CommuniGate Pro або на сервері Довідника стороннього виробника). В цьому випадку "корінь" CommuniGate Pro повинен зберігатися у віддалених Томе Зберігання, що вказує на такий зовнішній сервер. За замовчуванням "корінь" Довідника зберігається в Локальному Томе Зберігання з ім'ям Main.

Для того щоб вказати Серверу CommuniGate Pro що "корінь" Довідника і все дерево Довідника зберігаються на віддаленому сервері, виконайте наступні дії:

відкрийте настройки Тома Зберігання Main
перемістіть Том в фіктивне поддерево o = dummy
створіть Віддалений Том Зберігання RemoteRoot, вказавши в його Піддерево порожній рядок
налаштуйте Віддалений Том RemoteRoot так, щоб він мав відповідний доступ на віддаленому LDAP сервері
перевірте, що віддалений довідник доступний (використовуючи Перегляд Довідника CommuniGate Pro)
відкрийте установки Тома Зберігання Main і натисніть на кнопку Видалити Том

Записи Довідника можуть бути захищені (і, звичайно, дійсно захищені) від несанкціонованого доступу. Коли користувачі хочуть отримати доступ до захищених даними Довідника, вони повинні спочатку аутентифицироваться. Цей процес називається прив'язка і успішна аутентифікація "прив'язує" ( "binds") користувача до певного Повному імені записи (DN) в Довіднику.

Якщо користувач намагається прочитати або змінити дані Довідника, то для перевірки прав Доступу до Довідника використовується прив'язаний DN.

Коли користувач використовує Довідник через Веб інтерфейс користувача CommuniGate Pro або через XIMSS сесію, то прив'язаний DN є DNом записи цього Користувача:
uid = accountname, cn = domainname, o = MyCompany.
Додаткову інформацію дивіться в розділі центральний Довідник .

Коли доступ до Довідника здійснюється через модуль LDAP , Клієнт може аутентифицироваться за допомогою свого імені Користувача і пароля CommuniGate Pro. В цьому випадку прив'язаним DN буде DN Користувача.

До перетворення імені користувача в DN Користувача Довідника, перевіряються Права Доступу до Сервера користувача. Якщо користувач має право доступу до Довідника, то використовується спеціальний "майстер" Bind DN замість DN записи користувача. Клієнти з "майстер" Bind DN володіють необмеженими правами доступу до Довідника.

Для прив'язки через LDAP може використовуватися будь-який DN Довідника. Запис довідника з зазначеним DN повинна існувати, запис повинен містити атрибут userPassword, і значення атрибута повинно відповідати введеному паролю.

Якщо клієнт не аутентифицироваться, то використовується спеціальний Bind DN anyone.

Довідник CommuniGate Pro обмежує права клієнтів на читання, пошук і зміна записів Довідника. Довідник містить набір записів Прав Доступу, які дозволяють і забороняють операції в Довіднику для конкретних піддерев Довідника в залежності від прив'язаного DN клієнта.

Для завдання записів Прав Доступу відкрийте сторінку Права Доступу до Довідника:

Кожен запис Права Доступу має:

ім'я
що: DN, про якого йдеться запис; в рядках можуть використовуватися символи шаблону підстановки ( "*")
Bind DN: прив'язаний DN клієнта, до якого застосовується запис; в рядках можуть використовуватися символи шаблону підстановки ( "*")
тип: Заборонено або Дозволено
посилання на Запис, що задає права доступу

Кнопки Вниз і Вгору дозволяють вам пересувати записи в таблиці, збільшуючи або зменшуючи пріоритети записів.

Коли клієнт вимагає виконання операції пошуку, читання, зміни або будь-який інший операції із записом Довідника або з піддерево, що мають певний DN, Права Доступу перевіряються, починаючи з верхньої записи. Сервер шукає запис Прав Доступу, яка:

має в поле "Що" DN, що співпадає з DN, зазначеним у запиті клієнта
має в поле Bind DN значення, що збігається з прив'язаним DN клієнта
має операцію (видаляти, створювати), збігається з затребуваної операцій або має атрибут, що співпадає з атрибутом, використовуваним в операції

При виявленні такого запису Права Доступу тип запису вказує, дозволена операція або заборонена. Якщо не знайдено жодної записи Права Доступу, операція вважається забороненою.

Якщо клієнт має "майстер" прив'язаний DN (дивіться вище), то йому дозволені всі операції.

Коли клієнт вимагає здійснення операції типу "читання", то процедура повторюється для всіх атрибутів, які клієнт хоче отримати. Якщо операція заборонена для всіх зазначених атрибутів, то операція читання закінчується неуспішно. В іншому випадку операція виконується і клієнту повертаються всі атрибути, які він має право отримувати.

Коли клієнт вимагає здійснення операції типу "пошук", то процедура повторюється для всіх атрибутів, використовуваних у фільтрі пошуку. Якщо операція пошуку заборонена хоча б для одного з цих атрибутів, то вона закінчується неуспішно. У знайдених записів перевіряється RDN. Якщо RDN НЕ дозволений для читання, то запису не повертається клієнтові.

Якщо клієнт вимагає здійснення операції типу "перейменування", то процедура використовується двічі: перший раз для перевірки того, що клієнт має право видалити оригінальний запис Довідника і вдруге, щоб переконається, що клієнт має право створити запис Довідника в новому місці.

В поле Bind DN могут використовуват СПЕЦІАЛЬНІ рядки: anyone запису Права Доступу застосовується для будь-которого Bind DN, включаючі anyone (відсутній) Bind DN. brother запису Права Доступу застосовується, если Bind DN и цільової DN ма ють Загальний батьківський DN. Например, DNі uid = someuser, cn = domain1.com и uid = otheruser, cn = domain1.com є "братами" (brother). Такий спосіб завдання Bind DN доцільно надавати тим користувачам CommuniGate Pro, які отримують доступ до записів Довідника про інших користувачів, що знаходяться в цьому ж домені CommuniGate Pro. parent запис Права Доступу застосовується, якщо цільової DN є батьківським для Bind DN. Наприклад, DN cn = domain1.com є батьком для DNов uid = user1, cn = domain1.com і id = book1, uid = user1, cn = domain1.com. child запис Права Доступу застосовується, якщо цільової DN є батьківським для Bind DN. self запис Права Доступу застосовується, якщо цільової DN збігається з Bind DN. Такий спосіб завдання Bind DN доцільно надавати тим Користувачам CommuniGate Pro, які мають право змінювати значення атрибутів у своїх власних записів довідника.

Для того, щоб створити запис Права Доступу, введіть ім'я запису, цільової DN (поле Що) і Bind DN в останньому порожньому елементі в Таблиці Прав Доступу та натисніть на кнопку Модифікувати. Використовуйте кнопку Вгору для зміни пріоритету записи.

Для того, щоб видалити запис Права Доступу, зітріть її ім'я і натисніть на кнопку Модифікувати.

У середовищі динамічного Кластера підтримуються Общекластерние Права Доступу до Довідниках. Ці права доступу можуть бути задані на будь-якому членові кластера і передаються всім членам кластеру.
Общекластерние Права Доступу застосовуються після общесерверних Прав Доступу.
Для завдання Общекластерних Прав Доступу до Довідника відкрийте сторінку Права Доступу та натисніть на посилання Загальні для кластера.

Для завдання Прав Доступу до Довідника відкрийте сторінку Права Доступу та натисніть на посилання "Змінити" (відкриється запис Права Доступу):

Ці опції визначають, чи можуть клієнти з заданим Bind DN створювати або видаляти записи з заданим цільовим DN. У цьому полі перераховуються ті атрибути даних, які клієнти з заданим Bind DN можуть читати із записів із заданим цільовим DN. Імена атрибутів повинні відділятися символом коми. Для того, щоб дозволити клієнтам читати всі атрибути запису, використовуйте символ зірочка (*). У цьому полі перераховуються атрибути, які клієнти з заданим Bind DN можуть використовувати в фільтрах при пошуку в Піддерево Цільового DN.

У цьому полі перераховуються ті атрибути даних, які клієнти з заданим Bind DN можуть змінювати в записах із заданим цільовим DN.

Приклад запису Права Доступу: Що uid = *, cn = domain1.com Bind DN brother Тип Дозволено Атрибути для читання objectClass, officeEmail, roomNumber, cn, uid Ця запис дозволяє всім користувачам з домену domain1.com читати атрибути objectClass, cn, uid, officeEmail і roomNumber із записів Довідника інших користувачів Домену domain1.com. Приклад запису Права Доступу: Що cn = domain1.com Bind DN child Тип Дозволено Атрибути для читання objectClass, officeEmail, roomNumber Атрибути для пошуку cn, uid Ця запис дозволяє всім користувачам з домену domain1.com шукати в поддереве Довідника цього Домену по атрибутам cn і uid, але не по іншим доступним атрибутам.

Веб Інтерфейс Адміністратора CommuniGate Pro містить засоби для перегляду Довідника. Для того, щоб відкрити сторінку Перегляду Довідника, відкрийте розділ Довідник і натисніть на лінк Перегляд.

Сторінка Перегляду включає наступні поля DN:

Використовуючи це поле, введіть той DN записи / поддерева Довідника, який ви хочете бачити і натисніть на кнопку Перейти. Натисніть на кнопку Вгору для видалення самого лівого елемента DN і відкриття його "батьківської" записи Довідника.

Наступного панелі відображаються записи Довідника з зазначеним DN:

Якщо запис із зазначеним DN не може бути прочитана, то в цій панелі буде міститися повідомлення про помилку.

Наступного панелі відображаються всі дочірні записи.

Щоб обмежити число показуються записів, ви можете використовувати меню, що знаходиться на панелі.

Для пошуку зазначених записів, введіть в поле Фільтр LDAP рядок-фільтр (в форматі RFC 2254) і натисніть на кнопку Показати.

Елементи таблиці є дочірніми RDN і objectClass.

Натисніть на посилання з ім'ям дочірнього елемента RDN для того, щоб переглянути цю запис.

Веб Інтерфейс Адміністратора CommuniGate Pro дозволяє Адміністратору Сервера імпортувати з текстових файлів у форматах LDIF і "replog" зміни до Довідника:

Для імпорту даних до Довідника CommuniGate Pro натисніть на кнопку Огляд (Browse) і введіть ім'я LDIF файлу, що знаходиться на вашому комп'ютері. Натисніть на кнопку Імпортувати LDIF, щоб вставити всі записи з обраного LDIF файлу.

Для того, щоб застосувати до Довідника CommuniGate Pro набір змін записів, натисніть на кнопку Огляд (Browse) і виберіть "replog", що знаходиться на вашому комп'ютері. Натисніть на кнопку Імпортувати LMOD, щоб застосувати всі зміни з обраного файлу.

У середовищі динамічного Кластера підтримуються Общекластерние Тома Зберігання Довідника. Ці томи доступні на всіх членах кластера.

Коли налаштування Общекластерного Тома Зберігання змінюються на будь-якому членові кластера, нові налаштування автоматично стають доступні на інших членах кластера.

Коли Общекластерний Віддалений Том Зберігання використовується на будь-якому членові кластера, вихідні повідомлення LDAP організовується прямо на території цього Члена кластера. Необхідні завдання синхронізації виконуються віддаленим сервером LDAP.

Коли Общекластерний Локальний Том Зберігання використовується Контроллером Кластера, запит виконується локально. Коли Общекластерний Локальний Том Зберігання використовується на члені Кластера іншому, ніж Контролер, запит перенаправляється на поточний Контролер Кластера, використовуючи протокол LDAP (таким же чином, як для віддаленого Томів Зберігання на зовнішніх серверах LDAP).

Файли даних Общекластерних Томів Зберігання (настройки і, можливо, дані) зберігаються всередині директорії SharedDomains . При зупинці поточного Контролера кластера, коли Запасний Контролер Кластера приймає роль контролера, він перемонтують Общекластерние Тома Зберігання та працює з ними, як зі звичайними Локальними томами, тоді як інші члени кластера направляють запити для роботи з цими томами на поточний Контролер Кластера.

Для створення Общекластерного Тома Зберігання, відзначте прапорець Общекластерний (доступний тільки в середовищі динамічного Кластера).

Разработка сайта для Вашего бизнеса. Веб дизайн. Дизайн логотипа, фирменного стиля, рекламная фотография . Комплексный рекламный креатив.

CommuniGate Pro: Довідник