Установить 1с на nas
Внимание! Приложение HASP package (Hasplm) совместимо только с NAS Synology, основанными на аппаратной платформе х86. По состоянию на момент релиза программы HASP Package поддерживаются следующие модели на процессорах х86:
19 серия: RS1619xs+, RS1219+, DS1819+
18 серия: FS1018, RS3618xs, RS818RP+, RS818+, RS2818RP+, RS2418RP+, RS2418+, DS3018xs, DS418play, DS918+, DS718+, DS218+, DS1618+
17 серия: FS3017, FS2017, RS3617xs, RS3617RPxs, RS4017xs+, RS3617xs+, RS18017xs+, DS3617xs, DS1817+, DS1517+
16 серия: RS2416RP+, RS2416+, RS18016xs+, DS416play, DS916+, DS716+II, DS716+, DS216+II, DS216+
15 серия: RS815RP+, RS815+, RC18015xs+, DS3615xs, DS415play, DS415+, DS2415+, DS1815+, DS1515+
14 серия: RS3614xs, RS3614RPxs, RS814RP+, RS814+, RS3614xs+, RS2414RP+, RS2414+, DS214play
13 серия: RS3413xs+, RS10613xs+, DS713+, DS2413+, DS1813+, DS1513+
12 серия: RS3412xs, RS3412RPxs, RS812RP+, RS812+, RS2212RP+, RS2212+, DS3612xs, DS712+, DS412+, DS1812+, DS1512+
11 серия: RS3411xs, RS3411RPxs, RS2211RP+, RS2211+, DS3611xs, DS411+II, DS411+, DS2411+, DS1511+
10 серия: RS810RP+, RS810+, DS710+, DS1010+. Список совместимых моделей может расширяться по мере роста и изменения модельного ряда сетевых накопителей Synology.
Программа HASP package (Hasplm) является приложением для управления HASP-ключами, созданным для работы в составе ОС DSM для NAS Synology. Используя данный программный продукт, пользователь может устанавливать USB HASP-ключ непосредственно в NAS Synology для активации процесса аутентификации лицензий программного комплекса 1С. Такое решение позволяет отказаться от использования одного из ПК вашей локальной сети в качестве HASP-контроллера для программы 1С:Предприятие и осуществлять независимый настраиваемый доступ к базам со всех ПК. Базы данных при этом могут храниться на самом NAS Synology.
В настоящем руководстве мы подробно опишем пошаговую процедуру установки программы HASP package и инициации процесса верификации лицензий 1C:Предприятие.
Руководство включает в себя следующие части :
- Установка Hasplm и подключение HASP-ключа
- Установка 1C:Предприятие
- Создание базы данных
- Проверка и подтверждение состояния HASP-менеджера
Для начала работы вам потребуется:
- Сетевой накопитель Synology на базе платформы х86 (строго!)
- Скачанная программа HASP package для установки на NAS
- 1C HASP-ключ для подключения к NAS
- Компьютер, подключенный в туже сеть, что и NAS
- Установленная на ПК программа 1C:Предприятие
- Установленная на ПК программа Aladdin Monitor Установка Hasplm и подключение HASP-ключа
После установки пакета Hasplm, в Центре пакетов, нужно остановить его работу.
Подключить к серверу сам аппаратный ключ.
Запустить пакет.
На клиенте, в файле HASPNET.INI указать IP-адрес сервера Synology.
3. Подготавливаем debootstrap для запуска на другой системе. Т.к. DS412+ под i686, указываем архитектуру. Ставим его в папку ~/deboo:
Копируем свои репозитории в подготовленный образ:
И запаковываем в tarball-файл, чтобы было удобней переносить:
4. После инициализации DiskStation включаем ftp-сервер, через веб-интерфейс добавляем общую папку «share».
Переносим подготовленный на третьем этапе tarball-файл с системой (debootstrap) в эту папку;
5. Чтобы потом не собирать на слабеньком DS'е — сразу на виртуальной машине собираем пакеты XRDP:
Собираться будет долго, по окончанию забираем готовые пакеты из ./X11RDP-o-Matic/packages, помещаем в ту-же общую папку share на DS'е. Туда же копируем служебный скрипт из ./X11RDP-o-Matic/RDPsesconfig.sh. Виртуальная машина более не понадобится, ее можно выключать.
6. Подключаемся к DS по SSH. Система монтирует раздел в папку "/volume1", переходим в нее, в подпапку share (которая расшарена по ftp). Распаковываем созданный tarball-файл в /volume1/deboo;
7. Переносим настройки DNS и имя сервера:
8. Распаковываем все пакеты:
9. Делаем скрипты для монтирования/размонтирования системных папок, разрешаем их запуск:
10. Монтируем системные папки, и запускаем уже полноценный debian:
11. Все, теперь началась полноценная работа с debian в баше. Подготавливаем работу с репозиториями и обновляем пакеты:
12. Устанавливаем вероятно самую лёгкую графическую оболочку (иксы так-же устанавливаются при разрешении зависимостей):
13. Устанавливаем пакеты XRDP, собранные на пятом этапе:
14. Добавляем пользователей в систему, которые будут подключаться к серверу терминалов, запускаем скрипт RDPsesconfig.sh, полученный на этапе 5, который сгенерирует им нужные конфигурационные файлы;
15. Запускаем XRDP:
Теперь можно подключаться к серверу терминалов.
16. Скачиваем отсюда пакеты клиента и сервера для DEB-based систем. Распаковываем их в одну папку и устанавливаем:
17. Для платформы нужны дополнительные пакеты шрифтов и imagemagick, ставим их:
Дело сделано! Осталась рутина. В ту-же общую папку помещаем файловую базу 1С (уже распакованную демонстрационную версию Управление Торговлей). Подключаемся по RDP на сервер под своим пользователем, запускается оболочка, добавляем ярлык для запуска 1С Предприятия на рабочий стол, запускаем. 1С предлагает вам добавить базу. Добавляем существующую, указываем на общую папку, в которую была помещена база. Подключаемся в режиме предприятия, выбираем пользователя.
И еще пару слов напоследок, несмотря на то, что сервер терминалов запустить все таки удалось, считаем использование данной конфигурации для решения поставленной задачи нецелесообразным, в силу дороговизны и сложности в подготовке программной составляющей.
Есть офис с локальной сетью на 3 клиента и отдельный ПК с файловой базой 1С. Нагрузка на базу низкая, бекапы делаются иногда, инет в офисе медленный и нестабильный. Есть стремление повысить отказоустойчивость базы (бюджет 20 т.руб.). Подойдет ли для этого NAS сервер на RAID1? в 1С не силен, но так понимаю достаточно в NAS'e расшарить папку и прописать в клиентах новые пути к базе. Реализовывать буду не я, мне только нужно знать возможность такого варианта. Или есть другие варианты за тот же бюджет?
- Вопрос задан более трёх лет назад
- 1024 просмотра
В общем случае вполне работоспособный вариант. Хотя в вашем конкретном случае - неизвестно.
Тут все зависит от того что это за NAS и какие у него характеристики - может даже избыточно, а может явно не хватить.
Информации вы никакой полезнй не дали, поэтому неизвестно пойдет в вашем случае или нет.
Зато привели явно не нужную информацию - "инет в офисе медленный и нестабильный" - каким боком это относится к вопросу?
Что за базы - размер, конфигурация, количество активных пользователей, какая сеть в офисе - гигабит или нет, какая конфигурация NAS - процессор, память, диски.
Зная это можно уже точно сказать будет ли работать и как хорошо, и посоветовать варианты.
Файл 1Cv8.1CD - 1.3 Гб, 1С-Предприятие, 3 пользователя максимум, сеть 100Мбит
При таких данных работать будет, NAS должен быть не самым дохлым с более-менее адекватным процессором, и достаточным количеством оперативки, но за 15-20найти такой не проблема.
Сеть надо гигабитную, на сотку работать будет, но заметно медленнее.
Диски особой разницы нет - там нагрузка минимальная, можно и HDD можно и SSD, особого эффекта от SSD ждать не надо, будет работать не шустрее чем на HDD.
Но если мы говорим о HDD надо понимать, что на нем кроме баз не должно быть ничего - никаких файловых помомек, левых баз данных, операционных систем, и.т.п. - иначе не факт что справится.
При файловом режиме 1с работает следующим образом -
Читает большой кусок данных из файла 1Cv8.1CD, по сети, записывает его в папку пользователя на комьпютере пользователя, и там с ним активно работает.
В итоге -
Нагрузка на сам файловый сервер небольшая, чтение и запись в основном крупными блоками и не очень интенсивное.
Нагрузка на сеть - приличная, передается большой объем информации.
И самое главное огромная нагрузка на диск локального компьютера, где запущена 1с, и на память этого компьютера, ибо там идет вся основная работа.
Если клиентские компьютеры дохлые - будет работать все медленно и печально.
Чтобы например адекватно работала Бухгалтерия 3,0 нужно как минимум 8гб памяти на клиентской машине, и обязательно SSD под систему.
По поводу рэйда - зеркальный рэйд это хорошая штука, и временами незаменимая.
Но конкретно в вашем случае не вижу особого смысла в нем.
Вам важны бэкапы - раз в день, или несколько раз в день, чтобы не потерять информацию.
А сам по себе простой при трех пользователях как правило некритичен, поэтому зеркальный рэйд не сильно то и нужен.
А если уж делать все отказоустойчиво - то кроме рэйда нужно еще делать резерв по питанию, по сети, и.т.д., иначе просто нет смысла.
Цель - не потерять базу при выходе из строя жесткого диска. Если просто отключат электричество, то не страшно. Бекапы делаются Cobian'ом, а он требует чтобы к базе никто не обращался в момент создания бекапа, поэтому сделать частое автоматическое резервное копирование по расписанию с его помощью не знаю как.
Ну если так тогда рэйд.
Хотя практика показвает что такое бывает крайне редко.
Самые популярные причины потери базы -
1)Внезапное отключение питания- база битая.
2)Ошибка пользователя - пользователь случайно в общей папке удалил файл базы и все, или загрузил в него через конфигуратор другую базу - вообще популярная тема.
3)Ошибка софта - стороний софт при работе случайно удаляет файлы, бывали случаи.
4)Целенаправленные деструктивные действия пользователя - уволенный работник удаляет базу.
5)Вирусы и вредоносные программы - шифровальщик например зашифровал.
От всего этого защищает бэкап, а рэйд никак не защищает.
Если есть бэкап - ну полетел диск, печально, сбегали купили новый, залили базу из бэкапа - потеряли только внесенные данные за полдня. Если не устраивает можно делать чаще.
Обычно когда три пользователя это не критично, вот когда их триста, это уже критично, ибо остановка работы трехсот человек на несколько часов это серьезно, и это приличные деньги. Тут желательно кроме бэкапа еще и зеркальный рэйд, с обязательным резервированием по питанию, по сети, и.т.д.
Я обычно предпочитаю использовать под файловые базы не NAS, а обычный офисный компьютер с виндой, он ничем не хуже чем NAS, разве что более громоздкий и шумный.
Зато там полный доступ к файловой системе - и можно работать с теневыми копиями- каждый час делается теневая копия - всегда можно откатить базу на час назад.
Из этих же теневых копий делаются и бэкапы, хотя сами теневые копии бэкапами не являются.
Тот же самый кобиан прекрасно умеет работать с теневыми копиями.
А при теневом копировании совершенно пофиг кто там к базе обращается - можно делать в любой момент, потому что она при создании блокирует все потоки чтения- записи, и мгновенно делает снимок всего диска.
Т.е не важно сколько у вас там на диске данных - 1 мегабайт или один террабайт - снимок будет сделан мгновенно.
И самое главное - за рэйдом надо следить, иначе пользы от него нет.
Вот вам реальный пример -
Стоял файловый сервер под 1с, настраивали приглашенные грамотные спецы, все по уму, RAID1 разумеется.
Настроили и начали работать.
Работал как часы года три, потом у него полетел диск.
Но там же RAID1 - поэтому пользователи ничего не заметили, а админа своего не было и никто не мониторил, все спокойно работали на деградировавшем рэйде и никто даже не замечал проблем.
Через полгода вылетел второй диск - база потеряна.
Второй случай - тот же рэйд, сильный скачок напряжения в сети, выгорели цепи питания на мат. плате, и на обоих дисках.
Вот так одним махом из зеркального рэйда было потеряно сразу два диска.
Еще вариант - сервер стоял на полу, человек споткнулся и случайно его пнул.
Диски в этот момент активно работали, и не выдержали такого жесткого обращения и всей толпой дружно накрылись.
Так что не надо считать RAID1 панацеей от всех бед.
Он даже от выхода из строя дисков гарантированно не защищает.
Хотя повторюсь в некоторых случаях он обязателен и незаменим, но только в комплексе с другими мерами.
Да, судя по всему частые теневые копии даже надежнее будут, чем NAS. Надо будет продумать этот вариант. Спасибо за помощь, очень сильно помогли.
Znardi, Частые теневые копии + обязательный бэкап на другую машину, хотя бы раз день.
Делать можно хоть встроенными средствами винды, хоть кобианом, да банальный самописный скрипт в пару десятков строк на cmd засунутый в планировщик решает проблему.
Файл 1Cv8.1CD - 1.3 Гб, 1С-Предприятие, 3 пользователя максимум, сеть 100Мбит, NAS на два диска (наверное лучше SSD поставить?). Модель NASa или его характеристики лучше Вы мне посоветуйте в пределах 20 тыс.руб.
При таких данных работать будет, NAS должен быть не самым дохлым с более-менее адекватным процессором, и достаточным количеством оперативки, но за 15-20найти такой не проблема.
Сеть надо гигабитную, на сотку работать будет, но заметно медленнее.
Диски особой разницы нет - там нагрузка минимальная, можно и HDD можно и SSD, особого эффекта от SSD ждать не надо, будет работать не шустрее чем на HDD.
Но если мы говорим о HDD надо понимать, что на нем кроме баз не должно быть ничего - никаких файловых помомек, левых баз данных, операционных систем, и.т.п. - иначе не факт что справится.
При файловом режиме 1с работает следующим образом -
Читает большой кусок данных из файла 1Cv8.1CD, по сети, записывает его в папку пользователя на комьпютере пользователя, и там с ним активно работает.
В итоге -
Нагрузка на сам файловый сервер небольшая, чтение и запись в основном крупными блоками и не очень интенсивное.
Нагрузка на сеть - приличная, передается большой объем информации.
И самое главное огромная нагрузка на диск локального компьютера, где запущена 1с, и на память этого компьютера, ибо там идет вся основная работа.
Несколько лет назад, при выборе первого хранилища для дома, я смотрел в сторону «коробочных решений» по причине не особой осведомлённости в построении системы хранения на базе открытого ПО и обычного ПК. В тот раз выбор пал на 2-дисковую NAS — Shuttle KD20. Хранилище было компактным и тихим. RAID1 обеспечивал необходимую надёжность, а потребности в высокой производительности и расширенном функционале на тот момент не было. Этот NAS проработал почти 4 года, пока в один прекрасный момент не накрылась линия питания вентилятора. Диски раскалились до 60 градусов и чудом выжили. Я запаял вентилятор напрямую к материнке, но стал подбирать вариант на замену. В качестве второй NAS я выбрал 4-дисковую Synology. Задачи оставались те же, поэтому в функционал DiskStation Manager (DSM) я особо не вникал. Это продолжалось до тех пор, пока я не решил установить домашнее видеонаблюдение на несколько каналов. Не смотря на то, что Synology имеет собственный сервис видеонаблюдения, я остановился на Macroscop — была потребность в расширенном функционале и серьёзной аналитике. На своё счастье, я обнаружил в DSM новый пакет Virtual Machine Manager — гипервизор, с помощью которого я создал виртуальную машину и установил на неё Windows и Macroscop. На запись система работала нормально, встроенный Pentium 1,6 ГГц с трудом, но успевал отрабатывать задачи СХД и виртуальной машины. Но как только активировалась какая-либо аналитика — сервис отваливался по перегрузке процессора. В результате, я был вынужден начать поиски отдельного бюджетного Windows-девайcа с адекватной производительностью для реализации сервера видеонаблюдения, так как Synology необходимого уровня стоит недёшево. В тот самый момент я в очередной раз наткнулся в сети на статьи, посвящённые установке DSM на обычное железо и мой проект XPenology начался…
Стоимость необходимых комплектующих для новой хранилки была соизмерима со стоимостью Intel NUC, который я присматривал для сервера видеонаблюдения. Поэтому я решил отказаться от существующей Synology в пользу брата (и использовать её как удалённый бэкап), а себе собрать систему «всё в одном» на базе DSM.
Сборка платформы
1,5А-вентилятор снизил температуру дисков до 36-40 градусов. После доработки вытяжки из шкафа, уверен, что температура еще существенно упадёт.
Один SSD 2,5" под кэш я установил на стандартное крепление с одной стороны дисковой корзины. Его температура не превышала 30-32 градуса, и это при том, что он никак активно не охлаждается.
В качестве диска под пакеты DSM и быстрого раздела я установил M.2 SATA SSD в слот на материнской плате. Накопитель нагревался до 50 градусов, не смотря на прямой обдув. Я решил проблему установкой на него нескольких радиаторов — температура снизилась на 10 градусов.
У меня 2 постоянно активных USB-устройства: загрузчик XPenology и ключ Guardant от Macroscop. Чтобы не занимать внешние разъёмы я пристроил эти устройства внутри корпуса.
Готовое хранилище с высокой производительностью процессора и максимально компактными размерами со скрипом, но вписалось в свободные 6 юнитов.
Подготовка загрузчика
Для того, чтобы установить DSM нужен загрузчик, который представит железо в качестве СХД Synology.
В интернете много инструкций на эту тему, поэтому вдаваться в подробности не буду, но если появятся желающие — могу описать детали подготовки загрузочного устройства.
После установки валидной пары серийник/MAC и прочих параметров, образ для DS3615 заливается на любое устройство с которого можно грузиться. Можно использовать SATA DOM, но так как у меня SATA-порты на перечёт — я остановился на классическом варианте — USB флешке.
В BIOS необходимо удалить все загрузочные устройства кроме USB, а в параметрах SATA включить функцию HotPlug, чтобы новые диски определялись «на горячую», не дожидаясь перезагрузки.
Запуск
Прежде чем реализовать всё дома, я долго тренировался на различных платформах. Система без проблем мигрировала с компа на базе Celeron J1900 на сервер с 2 х E5-2680V4, а после на древний экспонат на базе 2 х E5645. Если есть виртуалки, то разумеется необходимо перед установкой ОС на виртуальную машину включать режим совместимости процессора. Вероятно это снижает производительность, т.к. процессор в виртуалке становится не реальный, а универсальный. Но зато, миграция проходит без трудностей и BSOD.
Настройка
Работа через загрузчик Xpenology почти не имеет ограничений по сравнению с оригинальным устройством. Из отличий можно отметить отсутствие функции QuickConnect — нет удалённого доступа к хранилищу через учётную запись Synology. Но у меня внешний IP — это ограничение для моего случая не актуально.
Также некорректно отображается модель процессора и кол-во ядер — информация зашита в загрузчике и всегда будет выглядеть как для DS3615xs: INTEL Core i3-4130 / 2 ядра. Но зато, частота определяется актуальная. Эта особенность не мешает определять и использовать гипервизору реальное кол-во ядер. Но и тут есть ограничения — Virtual Machine Manager увидит не более 8 ядер в системе. Поэтому ставить DSM на многоядерные конфигурации бессмысленно.
С объёмом ОЗУ всё в порядке — определялся и использовался весь объем (на практике до 48ГБ).
Интегрированные сетевые контроллеры определяются без проблем, а вот WiFi у меня не нашёлся. Предполагаю, что эта проблема может решиться добавлением драйверов, но, к сожалению, мои познания в Linux не позволяют мне этого реализовать. Если из читателей этой статьи найдётся человек, который сможет описать инструкцию по добавлению в сборку драйверов на беспроводной контроллер — я буду признателен.
Перед началом использования системы хранения необходимо создать RAID-группы. После перехода на первую Synology я оставил «зеркало», а 2 дополнительных диска пустил на Hot Spare. При переходе на Xpenology выбрал RAID5+HS, но потом добавил 4-ый диск в RAID6. Всё равно крутится и греется — пусть хоть с пользой.
Так как DSM обеспечивает как файловый, так и блочный доступ — перед созданием RAID-массива необходимо определиться с требованиями к типу будущего хранилища.
Я сразу создал несколько LUN для использования на домашнем мини-ПК и ноуте. Файловая шара — это хорошо, а диск с блочным доступом для установки программ — ещё лучше.
Далее создаётся необходимое кол-во LUN и разделов на RAID-группах, папки общего доступа и прочее. Описывать всем известный функционал Synology нет смысла. Все доступные пакеты расширения с описанием функционала доступны на официальном сайте.
Под мои задачи актуальными были следующие пакеты:
Virtual Machine Manager — собственно из-за него вся затея с Xpenology.
Пакет имеет более расширенный функционал, чем я использую, поэтому я решил протестировать его работу на нескольких нодах в режиме High Availability Cluster.
Но, вскоре был разочарован. Для кластера необходимо 3 ноды: активная, пассивная и хранилище. Автоматическая миграция виртуальных машин при выходе из строя активной ноды поддерживается только на виртуальных машинах Synology Virtual DSM — с виндой и прочими ОС не прокатит. Какой смысл на DSM поднимать кластер с виртуальными DSM я так и не понял…
В общем, более чем банальный гипервизор, я этот модуль не раскрыл для себя.
VPN Server — поддерживает PPTP, OpenVPN и L2TP/IPSec
PPTP, как у меня получилось выяснить, поддерживает только одно подключение бесплатно — его я использую для связи с удалённой Synology для бэкапа.
OpenVPN использую для подключения с iPhone и рабочего компьютера, а также для удалённого подключения LUN по iSCSI.
Hyper Backup — удобный, функциональный и, в то же время, лаконичный сервис резервирования.
Можно резервировать как папки так и LUN. Файловый бэкап можно сливать на другую Synology, на другой NAS и в облака. LUN резервируется только локально или удалённо на устройство Synology. Поэтому, если требуется бэкап луна в облако, как я понял, можно вначале его забэкапить в локальную папку, а уже её в облако.
Я использую 3 типа резервирования:
- Резерв на удалённую Synology — туда копируется всё, кроме папки бэкапа (в ней полный бэкап удалённой Synology).
- Бэкап только самого важного на Yandex-диск (через WebDAV)
- Дубль на Google-диск (есть в списке доступных облачных сервисов)
Выбрав метод и указав данные для авторизации на удалённом устройстве, помечаются папки для резервирования.
Далее настраивается расписание и параметры бэкапа.
Если выбрать шифрование, то потребуется ввод пароля на доступ к бэкапу. После создания задачи автоматически выгружается файл-ключ, который может заменить забытый пароль при восстановлении данных.
Шифрование на стороне клиента, на мой взгляд, очень полезно при резервировании в публичное облако. Если с архивом Ваших фото Google может делать всё что угодно, то зашифрованный бэкап тех же фото будет мало кому полезен.
Далее включается/настраивается ротация резервных копий.
Я использую режим Smart Recycle, но можно установить график ротации копий инкрементного резервирования на свой лад.
Модуль Hyper Backup работает только в паре с обратной частью — модулем Hyper Backup Vault
Этот сервис принимает удалённые копии и отвечает за их хранение.
Восстановление данных, приложений и настроек возможно как на текущей системе (при повреждении массива, утере данных и пр.), так и на новой такой же или абсолютно другой Synology или Xpenology. Для восстановления, при создании задачи резервного копирования, необходимо указать, что это не новая задача, а подключение к уже существующей. Hyper Backup увидит на удалённой машине необходимый бэкап и предложит выбрать версию копии по дате и времени.
На данный момент, это пока весь функционал, который мне удалось освоить и использовать.
Домашняя Xpenology продолжает работать без проблем — периодически обновляется DSM и пакеты, вычислительных мощностей с запасом, а по деньгам она обошлась мне в 1,5 раза дешевле Synology DS916+.
Synology High Availability Cluster
У меня вызывал интерес сервис High Availability Manager, который оказался не совместим с сервисом Virtual Machine Manager, так как тоже делает кластер, но уже по другому.
Для тестирования я поднял Xpenology на двух серверах на базе 2 x Xeon E5645. Сервера для этого кластера должны быть идентичными, IP-адреса статическими, второй порт каждого сервера соединён друг с другом напрямую (можно и через коммутатор, но эффективней так).
После подключения второй ноды тестируется подключение Heartbeat. Далее назначается имя кластера и статический локальный адрес. Во время слияния нод, конфигурация пассивной ноды приводится к состоянию активной, синхронизируются приложения, хранилище и данные. Обе ноды отваливаются для доступа по сети, и после создания — кластер доступен по своему новому адресу.
В зависимости от объема существующих данных, полная синхронизация массивов может занять немало времени, но кластер доступен к работе без отказоустойчивости уже через 10 минут после начала слияния.
После того как вторая нода будет полной копией первой, активируется режим высокой доступности.
Для проверки работы отказоустойчивости я создал LUN, подключил его по iSCSI и запустил объёмную задачу чтения и записи со своего ПК, совместно с проигрыванием видеоролика.
В момент активности я обесточил главный сервер. LUN не отвалился, процесс копирования не прервался, но приостановился секунд на 10-15 — это время потребовалось пассивному серверу взять роль активного и запустить упавшие службы. Воспроизведение также приостановилось на несколько секунд. После кратковременного простоя копирование данных и проигрывание видео продолжилось в штатном режиме без необходимости перезапускать процесс. Такой «провал» в большинстве случаев будет не заметен пользователям, если только не ведется воспроизведение видео без буферизации или запущены какие-либо другие процессы, требующие непрерывного доступа к хранилищу.
После включения первой ноды, она переходит в режим пассивного сервера. Запускается фоновый процесс синхронизации, после завершения которого режим высокой доступности снова восстанавливается.
Для замены ноды, в случае полного выхода из строя, необходимо освободить пассивный сервер.
Процедура привязки пассивного сервера аналогична процедуре создания кластера, вначале синхронизация — затем High Availability. Только при одном исключении — добавление происходит уже из интерфейса кластера, а не активного сервера.
Из минусов такого решения — высокая избыточность, ну а плюс — честная отказоустойчивость.
Основные затраты выпадают на диски, но для любителей RAID10 самое оно! Зазеркалировать две ноды с RAID5 или RAID6 — по дискам будет почти одно и то же. А вот отказоустойчивости прибавится кратно.
Понятное дело, что это не уникальный функционал, но зато «из коробки» и не требует особого опыта и знаний — только веб-интерфейс. А, учитывая, что Xpenology работает на любом железе, получается весьма интересное, производительное и отказоустойчивое решение для личного использования.
Каждая компания однажды сталкивается с необходимостью надежного хранения данных с доступом к ним именно тех сотрудников, которые по роду своей деятельности в компании связаны с этими данными. Одновременно встает задача по ограничению доступа к этим данным нежелательным лицам и, уж тем более, посторонним.
Одной из наиболее часто встречающихся практических задач в малых и средних компаниях является создание ограниченного доступа к бухгалтерским и прочим учетным базам.
Решение этой проблемы состоит из двух частей:
1) Ограничение доступа к данным методом наложения групповых и индивидуальных политик в домене или рабочей группе
2) Организация физической недоступности носителя информации или отделение места (устройства) хранения базы и обрабатывающего его сервера или клиентского ПК.
Для реализации обоих пунктов данного решения корпорация Synology предлагает использовать свои сетевые многодисковые накопители данных (NAS) как основное хранилище для бухгалтерских и иных критически важных баз данных.
- Имея возможность интеграции в Windows домены и поддерживая детальные настройки прав доступа к папкам и поддиректориям, сетевые накопители полностью решают вопрос разграничения доступа к хранимой на них информации.
- Обладая высокой скоростью обмена данными по сетевому интерфейсу (все модели NAS Synology имеют сетевой порт Gigabit Ethernet) и высокой нагрузочной способностью, сетевые накопители Synology обеспечат одновременный высокоскоростной доступ к хранимым данным как группе рабочих станции так и обрабатывающему серверу (например SQL-серверу).
- Благодаря небольшим размерам, минимальному уровню генерируемого шума, тепловыделения и отсутствию требований к кондиционированию места установки, сетевые накопители Synology могут иметь скрытый монтаж в любом удобном месте офиса или иного помещения, где доступно сетевое подключение. В настоящий момент, в связи с бурным развитием технологии Wi-Fi, проводные сетевые подключения могут быть заменены на беспроводные, что позволяет располагать сетевой накопитель с хранящейся ответственной информацией в любой точке помещения, а также и удаленно.
- Высокая степень надежности хранения информации обеспечивается поддержкой в сетевых накопителях Synology RAID-массивов уровня 1,5 и 6 в зависимости от конкретной модели NAS Synology.
В случае возникновения задачи синхронизации базы данных филиала и головного офиса или резервной репликации базы внутри сети предприятия с одного ресурса хранения на другой, корпорация Synology предлагает комплект встроенных в NAS Synology и устанавливаемых на клиентских ПК фирменных программных продуктов, обеспечивающих сетевое резервирование на удаленные ресурсы и внешние носители. Репликация баз в режиме резервирования может производиться как циклически, по заранее определенному расписанию, так и единовременно по команде администратора.
О гарантированной совместимости оборудования Synology с учетными программными комплексами и их базами говорит специально пройденная сертификация в компании 1С.
В результате тщательных тестирований сетевые накопители Synology официально получили статус «1С Совместимо. Система программ 1С: Предприятие».
Читайте также: