Об организации сетевого рабочего пространства в малой сети на уровне виртуальных серверов

Доброго времени суток, читатели! В данной статье я опишу структуру, которая получилась у меня в ходе размышлений о настройке виртуального рабочего пространства для сети с небольшим числом пользователей (кафедральной в университете). Основные задачи: хостинг ^[1] кафедрального сайта (Drupal), собственные репозиторий и вики, файлообменник (или сетевой диск), доступ к сети вне помещений кафедры.

Данная работа преследует две цели:

• узнать мнение опытных системных администраторов о таком подходе к настройке рабочего пространства (прошу, критикуйте)
• в случае, если подход неверен, статья тем не менее останется перечислением технологий, среди которых кто-нибудь может найти подходящие и ему (например, не слышал по какой-то причине об ownCloud)

Используемая система — Ubuntu 12.04 Server x64. Конфигурация физического сервера: i5 второго поколения, 8 Гб RAM, HDD 5400 1 Тб.

Инструменты

Drupal ^[2]. Исторически сложилось (tm), что сайт работает на CMS Drupal. Drupal написан на PHP, предоставляет выбор, какую базу данных использовать для хранения содержимого. Настройка Drupal вместе с MySQL и nginx на Ubuntu 12.04, например, тут [http://bikulov.org/post/49094056366/ubuntu-server-12-04-drupal-7-nginx-mysql]

RhodeCode ^[3] Веб-приложение для работы с репозиториями Git и Mercurial. У него есть некоторые заморочки во внутреннем строении (например, повесить хук на событие в RhodeCode весьма сложнее, чем в голом Mercurial). Однако, вы не столкнетесь с ними, пока не полезете внутрь, а это может и не понадобиться. Инструкция ^[4] по настройке для Ubuntu 12.04 с nginx.

DokuWiki ^[5] Вики-система, не использует базу данных, а хранит страницы в виде файлов на жестком диске. Причем, при добавлении файла на диск, он появляется в вики, и наоборот. Очень удобно, если хочется написать приложение для работы с вики, а разбираться с XML-RPC ^[6] нет времени и желания. Инструкция ^[7] по настройке для Ubuntu 12.04 с nginx.

ownCloud ^[8] Онлайн-хранилище файлов на собственном сервере (то есть «аналог Dropbox»). Позволяет внутри себя просматривать PDF и прослушивать аудиофайлы, имеет клиенты для различных платформ.

nginx ^[9] В качестве веб-сервера используется nginx. Это менее удобно в плане установки из репозиториев, т.к. тот же Drupal в репах Ubuntu использует Apache, поэтому первого приходится устанавливать руками.

LDAP ^[10] Аналог домена в Windows. Централизованная работа с учетными записями пользователей. В свое время я намучился с его настройкой (не помню уже, почему). Поэтому предлагаю вам два руководства, которые точно работают: сервера ^[11] и клиента ^[12].

VPN ^[13] Хорошая инструкция ^[14] по настройке VPN есть в серверном руководстве Ubuntu.

VirtualBox ^[15] Технология виртуализации роли не играет. В данной работе был выбран VirtualBox по следующим причинам: я не смог найти, почему использование VirtualBox на боевом сервере это плохо — у меня аптайм на нем достигает 2 месяцев (потом перезагрузка для установки обновлений), глюков не встречал. Спорить не буду, как наткнусь на недостатки — сконвертирую ^[16] vdi в raw и перейду на Xen.

Bittorrent Sync ^[17] Резервное копирование реализовано ^[18] с помощью Bittorrent Sync. Для сохранности данных (код-то закрытый!) предлагается использовать гибридное ассиметричное шифрование ^[19]. Ассиметричное шифрование дорого, поэтому и гибридное: генерируется длинный ключ, который сохраняется в файл. С этим ключом происходит шифрование большого файла. Файл с самим ключом затем шифруется ассиметрично.

Структура сети

В простейшем случае все виртуальные машины размещаются на одном физическом сервере. Этот вариант и будет описываться в дальнейшем. Используется 4 виртуальных системы и одна хостовая (hostserver), установленная непосредственно на железо.

Виртуальные системы, обозначенные на схеме vmserver-web, vmserver-dev и vmserver-drive занимаются только хостингом ^[1] определенного веб-приложения. Мотивация разделения следующая: Drupal крутит основной и мало меняющийся сайт, DokuWiki/RhodeCode используются в активном режиме, может создаваться несколько однотипных вируальных машин для разных целей, ownCloud пару раз вешал мой домашний сервер, его хотелось бы отделить от остального.

Виртуальная машина vmserver-net крутит настроенные LDAP и VPN. Сетевое подключение для всех виртуальных машин — NAT. Все виртуальные машины соединены подключены между собой по VPN. Для vmserver-net проброшены заданные VPN и LDAP внутрь порты из хостовой системы.

При запросе по http/https запрос разбирается nginx на хостовой машине и, в зависимости от адреса, пересылается по внутренней VPN на нужную виртуальную машину. Использование VPN позволяет сети оставаться функциональной даже в случае, если vmserver-web, vmserver-dev и vmserver-drive будут физически находиться где-то еще. Просто добавлять новые виртуальные системы, требуется только модификация конфига nginx.

Теперь немного о безопасности: резервное копирование и шифрование. Доступ по ssh для всех машин разрешен только по ключу. Вне VPN наружу торчит только ssh хостовой машины. Доступ к виртуальным машинам по ssh возможен только внутри своей VPN. Резервное копирование представляет собой следующий набор операций на хостовой машине: пауза виртуальной машины, сжатие образа gzip'ом и гибридное шифрование полученного архива. Зашифрованные архив и файл кладутся в папку, синхронизируемую с помощью btsync между несколькими физическими машинами. (По мотивам stackoverflow предлагаю удобные скрипты: инициализация ^[20] (установка необходимых пакетов и генерация ключа с заданным именем), шифрование и дешифрование ^[21] (в случае шифрования нужно указать файл, который шифровать, и публичный ключ, оригинальный файл будет удален. В случае дешифрования нужно указать файл и приватный ключ, шифрованный файл будет удален. Имя файла с ключом симметричного шифрования будет определено автоматически.).

При резервном копировании виртуальных машин очень большой оверхед, но разворачивать такую резервную копию очень просто. А синхронизация внутри своей физической сети 3 Гб в сутки представляется незначительной (примерно столько занимает 4 архива систем сейчас).

Заключение

Описанный подход позволяет, на мой взгляд, достигнуть модульности и безопасности при организации виртуального рабочего пространства. Сохранение функциональности при переносе любой из фиолетовых (vmserver-web, vmserver-dev или vmserver-drive) виртуальных машин на другую физическую машину обеспечивает масштабируемость.

С другой стороны, в комментариях хотелось бы услышать мнение сообщества по поводу такого способа организации виртуальных серверов, использованных инструментов и вопросов, обозначенных во введении.

Автор: Kenarius

Источник ^[22]