Собственное корпоративное облако ownCloud с NGINX во frontend и несколькими серверами backend

  • Tutorial

1. Схема


Имеем:
  • Frontend — NGINX проксирующий сервер для принятия и распределения нагрузки (IP — 1.2.3.4 — внешний, IP — 192.168.5.10 — внутренний DMZ) по хорошему он тоже должен стоять за firewall-ом, но тут схема для простоты понимания.
  • Два сервера с поднятыми ownCloud
  • cloud-1 IP — 192.168.1.11
  • cloud-2 IP — 192.168.1.12
  • Хранилище файлов NFS-storage IP — 192.168.1.20 для размещения данных пользователей с доступом по NFS.

image

2. Установка ownCloud


Собственно все действия по мануалу и математика из репозиториев.
Система Ubuntu 12.03 LTS — LAMP (при установке LAMP не забудьте пароль root)
Для работы с LDAP необходимо доставить php5-ldap
$sudo apt-get	install php5-ldap

Для хранения данных мы используем отдельный сервер с доступом по NFS.
На сервере-хранилище NFS-storage ставим nfs сервер
$ sudo apt-get install nfs-kernel-server

Правим /etc/exports добавляя строчку:
/var/owncloud 192.168.1.0/24(rw,sync,no_root_squash,no_subtree_check)

Создаем папку и меняем ей права:
$sudo mkdir -p /var/owncloud
$sudo chown root:www-data /var/owncloud

Перепускаем nfs сервер:
$sudo /etc/init.d/nfs-kernel-server restart

С хранилкой закончили.
На серверах-клиентах nfs ставим:
$ sudo apt-get istall nfs-common

Правим vim /etc/rc.local перед exit 0 добавляем строчку: (для монтирования NFS папки при загрузке системы, пишу в этот файл потому как использование /etc/fstab вызывало тяжело преодолимые проблемы)
/bin/mount -t nfs -o user,rw,hard 192.168.1.20:/var/owncloud /var/cloud

Создаем папку /var/cloud и меняем ей права:
$sudo mkdir -p /var/cloud

$sudo chown root:www-data /var/owncloud

Для проверки монтирования
$sudo mount.nfs 192.168.1.20:/var/owncloud /var/cloud

Далее ставим собственно облако на два сервера.
Скачиваем и ставим ключ:
$wget http://download.opensuse.org/repositories/isv:ownCloud:community/xUbuntu_12.04/Release.key
$sudo apt-key add - < Release.key 

Добавляем репозитории и ставим облако.

$sudo sh -c "echo 'deb http://download.opensuse.org/repositories/isv:/ownCloud:/community/xUbuntu_12.04/ /' >> /etc/apt/sources.list.d/owncloud.list"
$sudo apt-get update
$sudo apt-get install owncloud

Заходим you_ip/owncloud
  • Вписываем администратора “admin”
  • Придумываем пароль “password”
  • Путь где будут храниться файлы пользователей /var/cloud (эту папку мы подключаем по NFS с хранилища)
  • Выбираем MySQL
  • Пользователь MySQL “root” (или тот что завели сами)
  • Пароль пользователя root (который вводили при установке LAMP или от созданного пользователя)
  • Имя базы данных “cloud”
  • Сервер баз данных “localhost”

Жмем FINISH
И заходим под созданным пользователем admin в веб интерфейс owncloud.
Я правил /var/www/index.html для перенаправления на страницу входа на облако.
<html>
    <head>
        <meta HTTP-EQUIV="REFRESH" content="0; url=/owncloud/">
    </head>
</html>

Все это проделываем на обоих серверах CLOUD-1 и CLOUD-2.

3. Установка и настройка NGINX


На сервере NGINX
$sudo apt-get install nginx

Создаем файл конфигурации для сайта перенаправления
$ sudo vim /etc/nginx/sites-available/cloud

Правим до такого состояния.
upstream myCloud {
    ip_hash;						#что бы сохранялась сессия
    server 192.168.1.11:80;
    server 192.168.1.12:80;
}
server {
    listen       1.2.3.4:443 ssl;		# работаем через SSL
    server_name  owncloud.site.org;
    ssl_certificate     /etc/ssl/certs/site.pem;	# сертификат
    ssl_certificate_key /etc/ssl/private/site.key; # ключ сертификата
    client_max_body_size 200G; # максимальный файл для загрузки
    location / {
    proxy_pass   http://myCloud;
    proxy_set_header   Host   $host;
    proxy_set_header   X-Real-IP  $remote_addr;
    proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
       }
 }

Создаем ссылку
$sudo ln -s /etc/nginx/sites-available/owncloud.site.org /etc/nginx/sites-enabled/owncloud.site.org

Правим страницу по умолчанию, перенаправляя все запросы на SSL.
$sudo vim /usr/share/nginx/www/index.html

<html>
    <head>
        <meta HTTP-EQUIV="REFRESH" content="0; url=https://owncloud.site.org/cloud/">
    </head>
</html>

Перпускаем nginx
$sudo /etc/init.d/nginx restart


Теперь при все запросы на owncloud.site.org будут перенаправлены на owncloud.site.org/cloud

Сессия SSL устанавливается между клиентом и NGINX, между NGINX и облачными серверами обычный HTTP.

На этом этапе можно зайти на owncloud.site.org и должны попасть на приглашение ввода логина-пароля одного из наших cloud1(2) серверов.

После всех настроек мы получаем кластер но:
Когда пользователь настраивает свой профиль и выполняя действия с приложениями на сервере cloud-1 все эти данные хранятся в базе MySQL сервера cloud-1. При следующем входе он попадет на другой сервер кластера cloud-2 где ни действий ни настроек нет.
Для устранения этого нем необходимо синхронизация баз MySQL между серверами cloud-1 и cloud-2. Причем стандартная конфигурация репликации MySQL это master — slave, т.е. изменения на master реплицируются на slave но не наоборот. Нам же необходимо два равноправных сервера master — master.

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

4. Настройка репликации master — master MySQL


На cloud1
# vim /etc/mysql/my.cnf 

добавляем строчки
[mysqld]
#Replication
log-bin=mysql-bin
binlog_format=mixed
server-id = 1      /* для каждого сервера уникальный */
slave-compressed = 1
binlog-do-db = cloud  /* название базы для репликации */
#bind-address           = 127.0.0.1 /* что бы можно было подулючаться с других машин*/

На cloud2
# vim /etc/mysql/my.cnf 

добавляем строчки
[mysqld]
#Replication
log-bin=mysql-bin
binlog_format=mixed
server-id = 2      /* для каждого сервера уникальный */
slave-compressed = 1
binlog-do-db = cloud  /* название базы для репликации */
#bind-address           = 127.0.0.1 /* что бы можно было подулючаться с других машин*/

Заводим пользователя для репликации на обоих серверах.
На cloud1
пользователь repl2 с доступом с IP 192.168.1.11 и паролем u_pass (должны быть права на базу cloud и привелегии SELECT, RELOAD, SUPER, REPLICATION SLAVE)
mysql> grant replication slave on *.* to 'repl2'@192.168.1.12 identified by 'u_pass';

На cloud2
пользователь repl1 с доступом с IP 192.168.1.12 и паролем u_pass (должны быть права на базу cloud и привелегии SELECT, RELOAD, SUPER, REPLICATION SLAVE)
mysql> grant replication slave on *.* to 'repl2'@192.168.1.11 identified by 'u_pass';

Далее приводим обе базы в идентичное состояние:
На cloud1
mysql> FLUSH TABLES WITH READ LOCK;
mysql> show master status;
+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000009 |  107     | cloud        |                  |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Делаем дамп базы cloud
#mysqldump -u root -p cloud > /home/user/cloud.sql
mysql> UNLOCK TABLES;

Копируем на cloud-2
$scp /home/user/cloud.sql user@192.168.1.12:/home/user/cloud.sql

На cloud2
далее настраиваем slave;
mysql> USE cloud;
mysql> SOURCE /home/user/cloud.sql 
mysql> CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000009';
mysql> CHANGE MASTER TO MASTER_LOG_POS=107;
mysql> stop slave;
mysql> CHANGE MASTER TO MASTER_HOST='192.168.5.11', MASTER_USER='repl2', MASTER_PASSWORD='u_pass';

заметка
(здесь надо заметить что эти «CHANGE MASTER TO MASTER_HOST='192.168.5.11', MASTER_USER='repl2', MASTER_PASSWORD='u_pass';» данные раньше писались в файл MySQL /etc/mysql/my.cnf
master-host = 192.168.1.11
master-user = repl2
master-password = <пароль>
но были вынесены в отдельную команду в консоли MySQL)


mysql> start slave;
mysql> show slave status/G;

Должно быть что то типа этого:
лог
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.11
Master_User: repl2
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mysql-bin.000014
Read_Master_Log_Pos: 107
Relay_Log_File: mysqld-relay-bin.000017
Relay_Log_Pos: 210
Relay_Master_Log_File: mysql-bin.000014
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 107
Relay_Log_Space: 513
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Replicate_Ignore_Server_Ids:
Master_Server_Id: 2
1 row in set (0.00 sec)

На cloud1
Поскольку базы сейчас одинаковые делать дамп и восстанавливать его нет необходимости.
Нам надо настроить cloud-1 как slave к cloud-2
mysql> USE cloud;
mysql> stop slave;
mysql> CHANGE MASTER TO MASTER_HOST='192.168.5.12', MASTER_USER='repl1', MASTER_PASSWORD='u_pass';
mysql> start slave;
mysql> show slave status/G;

Вывод должен быть подобен как на cloud-2

Параметры … должны быть YES на cloud-1 и cloud-2.
Slave_IO_Running: Yes
Slave_SQL_Running: Yes


На этом этапе есть небольшая проблема, вы можете зайти под локальным пользователем на сервер cloud-1 а cloud-2 говорит что пароль не верный (или наоборот) :(. Причина — СОЛЬ :)
Имеется файл /var/www/owncloud/config/config.php в котором есть переменная
'passwordsalt' => '6d84a4d8cb3cf5439c05647ceb45682a',
и у каждого сервера облака значение будет разное. Необходимо скопировать это значение с сервера на который вы зайти можете и вставить там где это невозможно.

Для проверки заходим на 192.168.1.11 и 192.168.1.12 под одним пользователем и создаем в календаре событие на сервере cloud-1 а на cloud-2 оно должно появиться автоматически (F5).
Имеем на выходе:
  • NGINX во фронтэнде для динамического распределения нагрузки
  • Несколько серверов в бакэнде для повышения скорости отдачи при наплыве пользователей

5. Клиенты


  • Для Linux, Windows и MacOC — бесплатны (минус — нельзя указать несколько разных папок для синхронизации)
  • Для Android и iPhon/iPad — 0.99$

Воткактотак :)

6. Ссылки


www.opennet.ru/tips/info/1205.shtml
www.mysql.ru/docs/man/Replication_HOWTO.html
habrahabr.ru/post/86496
google.com
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 26

    +6
    когда уже этот ваш оунклауд перестанет ложиться при количестве файлов больше 5к?
      –1
      ну… можете взять исходники и выправить его до идеального состояния.
        +1
        Вот тут SRC
      +2
      Не знаю сознательно или нет, но в
      Создаем ссылку
      $sudo ln -s /etc/nginx/sites-available/cloud.ce...
      вы спалили свой адрес.
      А теперь, собственно, вопросы:
      — какую верси используете?
      — сколько файлов хранится?
      — если много, то довольны ли пользователи? :)
        +1
        Спасибо :) да есть немного, (выправил)
        могу дать доступ для теста.
        Ответы:
        — официальную из репозиториев ownCloud 6.0.0a (stable)
        — пока это все в тестовой эксплуатации, файлов маловато для того что бы можно было сказать что то конкретное
        — пользователей узкий круг тестеров
      • НЛО прилетело и опубликовало эту надпись здесь
          0
          ownCloud это альтернатива не seafile/btsync/dropbox а скорее google drive — там онлайн-редакторы и подобное.
            0
            seafile это тоже умеет.
          • НЛО прилетело и опубликовало эту надпись здесь
            • НЛО прилетело и опубликовало эту надпись здесь
              0
              Seafile однозначно рекомендую, настраивается за 1 минуту, клиент вполне себе годный, есть и мобильный. Работает стабильно.
              +2
              — Почему именно такая архитектура?
              — Почему 2 сервера owncloud? Но перед ними только один прокси, при подении которого, упадет все.
              * неужели owncloud у вас столько кушает ресурсов, что надо 2 сервера?
              — Почему один storage? при подении которого…

              Если уже делать, то я бы ставил 2 сервера, которые одновременно и storage или 2 storage'a отдельно.
                0
                Почему 2 сервера owncloud? Но перед ними только один прокси, при подении которого, упадет все.
                Опередили.
                Тоже не понял данной странной конструкции, такое прожорливое приложение? По идее нет, или надо очень большое количество пользователей, что бы это увеличением CPU, RAM не решалось.

                Если говорить про дублирование, тут схема усложняется, а отказоустойчивость не добавляется. Сторадж тоже должен быть дублирован, либо делать его на cloud1+cloud2. Балансировщик надо тоже дублировать, хотя бы в пассивном режиме.

                Ну это все «по правильному», а тут автор не пояснил почему 2 сервера owncloud, может конечно в этом есть какой то глубокий смысл…
                  –3
                  — Это вариант, вы можете сделать по другому.
                  — Можно и три и… сколько сил хватит.
                  Почему один прокси? а зачем больше? его задача перераспределять пользователей между серверами. Реально ownCloud довольно неповаротлевый.
                  — Storage это БОЛЬШАЯ хранилка, файловый сервер. IMHO не рационально держать две большие хранилища и организовывать между ними синхронизацию. Два (три, 4… n) маленьких но быстрых сервера должны быстро обрабатывать запросы, а хранить данные лучше отдельно. И так достигается лучшая маштабируемость, наращивание мощностей.
                    +1
                    ^ omg.

                    Как мне кажется, так это то, что это очередное пособие, «как не нужно делать».
                    Не в обиду, но я бы взялся и переписал всё.
                  +2
                  Корпоративное облако? С 2-мя SPOF? Ого…
                    +2
                    Скорее всего, все воткнуто в один свитч и смотрит в интернет через единственный роутер, потому прибавьте еще 2.
                    И мы еще не знает, по 2м ли энерговводам записаны серверы. Впрочем, датацентр определенно один, потом не +2, а +3.
                      0
                      Ой Ой, вы размахались на сервис-провайдера, наши запросы и возможности куууууда скромнее. :)
                      Некий корпоративный сервис.
                      Сотрудник получает почту, облачное место, jaber и т.д., все с авторизацией LDAP
                        +6
                        при этом вы умудрились потратить 4 сервера получив в итоге решение которое упадет от сквозняка из открытой форточки
                    0
                    ну да. и что будет с этим всем после развала линка между серверами — подумать страшно
                      +3
                      Да можно даже линк не рвать, достаточно 2м клиентам, которые попадут на разные бэкенды, одновременно попытаться добавить новую строчку в одну и ту же таблицу или обновить одно и то же поле.
                      0
                      Hoper а не знаете насколько ownCloud хорошо живет если держать его не на отдельном доменном имени, как у Вас, а в папке? типа site.com/cloud

                      Просто денег на отдельный ssl сертификат жаба давит, а на wildcard тем более :)
                        0
                        Во-первых, есть StartSSL, который выдаст вам серверный сертификат бесплатно. Во-вторых, для личных целей можно и самоподписанный использовать.
                          +1
                          Так он по умолчанию создает алиас site.com/owncloud и живет именно там, просто я сделал редирект на ..../cloud/, оставил возможность для стартовой страницы.
                          0
                          Выглядит красиво, но php же. Ставили, посмотрели. Прикрутили сторадж на ceph. Половина свистелок не работает. Те, которые работают — слишком ресурсоемкие и не очень быстрые. При количестве пользователей более десяти — возникают неизбежные проблемы с производительностью. Как это все масштабировать, даже с распределенным хранилищем — неясно.
                          На nas дома я бы поставил. Куда-то в продакшн = будет все время лежать и будить админа.
                          Как-то так.
                            0
                            А это будет корректно работать по HTTPS, если перед NGINX добавить iptables+nat на отдельной машине?

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое