Хранилище данных отдельно, приложения отдельно.
Сейчас я использую один сервер для всех необходимых служб. Но планирую разделить все на два сервера. Я хочу, чтобы у меня было два сервера, один для хранения и доступа к данным. Другой только для исполнения приложений. Возможно будет все таки один физический сервер. Но основная система будет только хранить данные и предоставлять к ним доступ (MYSQL, FTP, SMB, NFS, etc (что посоветуете еще ?)) Дело в том, что я использую chef для настройки всего и вся. И мне очень хочеться добиться быстрого развертывания второго сервера через эту систему. Но для этого мне необходимо сначало разделить данные от приложений. Чтобы быстро развернуть приложения нужно, чтобы данные были всегда доступны. Предположим в план развертывания системы redmine были внесены серьезные изменения. Но доступ к данным остался прежним. Я могу удалить контейнер и развернуть его снова, не беспокоясь о данных, которые храняться на другом сервере. Во первых чтобы за второй сервер можно было не беспокоиться вообще.Во вторых чтобы все данные были в одном месте - их будет удобно архивировать.В третьих так как конфигурация служб доступа к данным практически статична, добиться максимального uptime сервера доступа к данным. По поводу третьего добавлю, что поваренные книги для развертывания bacula, redmine, dns, dhcp, ldap в процессе разработки и мне постоянно нужно эксперементировать с ними. Подымать development копии, удалять их и так далее. Мне было бы проще отрефакторить рецепты так, чтобы при развертывании указывать какие данные и откуда использовать для того, чтобы развернуть полностью рабочие копии тестируемых служб. У меня есть следующие данные: 1. База данных mysql ticket tracker'а2. Репозитории git, hg, доступ к которым нужен с тикет трекера (~ объем примерно 4Гб).3. Данные (файлы и папки ) папки обмена файлами доступной по протоколым NFS, SMB, FTP4. Мелкие данные такие как сертификаты https, ключи для расшифровки, ldif файлы с содержанием ldap каталога, конфиги различных служб (DNS, DHCP) и местных скриптов и так далее. Соответсвенно есть службы, которые пользуются этими данными на другом сервере:1. Например redmine, который разворачивается и работает в контейнере, которому нужен доступ к базе данных mysql.2. Например репозитории нужны веб серверу работающему в контейнере redmine для расшаривания доступа к ним через HTTPS3. SMB, NFS, ftp - которые я скорее всего подыму на сервере данных, т.к. объемы большие и разностить службы от этих данных по гигабитной сети не совсем правильно.4. Остальные разношерстные данные нужны различным виртуальным машинам (контейнерам) по объему этих данных не много (гигабитной сети за глаза). Возникает вопрос как эти данные предоставлять в доступ виртуальным контейнерам, работающим на другом сервере ? Какими протоколыми это реализовать? Что посоветуете использовать ? NFS, iSCSI, glusterfs, etc ? Я например неиспользовал ни когда iSCSI. Как он подходит например для доступа к репозиториям из контейнера redmine и последующего расшаривания их по https? В принципе поидее NFS можно использовать для сущностей описанных в пункте 4. Но может есть что то другое ? Спасибо! --Faithfully yours, Vladimir Skubriev
Re: Хранилище данных отдельно, приложения отдельно.
Vladimir Skubriev - Debian-russian @ Thu, 19 Jun 2014 12:16:05 +0400: VS 1. База данных mysql ticket tracker'а VS 2. Репозитории git, hg, доступ к которым нужен с тикет трекера (~ объем примерно 4Гб). VS 3. Данные (файлы и папки ) папки обмена файлами доступной по протоколым NFS, SMB, FTP VS 4. Мелкие данные такие как сертификаты https, ключи для расшифровки, ldif файлы с содержанием ldap каталога, конфиги различных служб (DNS, DHCP) и местных скриптов и VS так далее. VS VS Соответсвенно есть службы, которые пользуются этими данными на другом сервере: VS 1. Например redmine, который разворачивается и работает в контейнере, которому нужен доступ к базе данных mysql. VS 2. Например репозитории нужны веб серверу работающему в контейнере redmine для расшаривания доступа к ним через HTTPS VS 3. SMB, NFS, ftp - которые я скорее всего подыму на сервере данных, т.к. объемы большие и разностить службы от этих данных по гигабитной сети не совсем правильно. VS 4. Остальные разношерстные данные нужны различным виртуальным машинам (контейнерам) по объему этих данных не много (гигабитной сети за глаза). VS VS Возникает вопрос как эти данные предоставлять в доступ виртуальным контейнерам, работающим на другом сервере ? VS VS Какими протоколыми это реализовать? VS VS Что посоветуете использовать ? NFS, iSCSI, glusterfs, etc ? Не могу сказать, что у меня есть богатый опыт, но. Пп. 2 и 4 я бы делал через NFS, а в случае контейнера на том же физическом сервере - через mount --bind. В пп. 1 и 3 протоколы уже указаны. NFS - штука простая, странного не хочет, скорость у нее вменяемая, а экстремально высокой скорости или горячего резервирования в запросе не стоит. -- To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87ppi5nt4w@wizzle.ran.pp.ru
Re: Хранилище данных отдельно, приложения отдельно.
19 июня 2014 г., 12:16 пользователь Vladimir Skubriev vladi...@skubriev.ru написал: У меня есть следующие данные: 1. База данных mysql ticket tracker'а 2. Репозитории git, hg, доступ к которым нужен с тикет трекера (~ объем примерно 4Гб). 3. Данные (файлы и папки ) папки обмена файлами доступной по протоколым NFS, SMB, FTP 4. Мелкие данные такие как сертификаты https, ключи для расшифровки, ldif файлы с содержанием ldap каталога, конфиги различных служб (DNS, DHCP) и местных скриптов и так далее. Соответсвенно есть службы, которые пользуются этими данными на другом сервере: 1. Например redmine, который разворачивается и работает в контейнере, которому нужен доступ к базе данных mysql. 2. Например репозитории нужны веб серверу работающему в контейнере redmine для расшаривания доступа к ним через HTTPS 3. SMB, NFS, ftp - которые я скорее всего подыму на сервере данных, т.к. объемы большие и разностить службы от этих данных по гигабитной сети не совсем правильно. 4. Остальные разношерстные данные нужны различным виртуальным машинам (контейнерам) по объему этих данных не много (гигабитной сети за глаза). Возникает вопрос как эти данные предоставлять в доступ виртуальным контейнерам, работающим на другом сервере ? Какими протоколыми это реализовать? Что посоветуете использовать ? NFS, iSCSI, glusterfs, etc ? Я например неиспользовал ни когда iSCSI. Как он подходит например для доступа к репозиториям из контейнера redmine и последующего расшаривания их по https? В принципе поидее NFS можно использовать для сущностей описанных в пункте 4. Но может есть что то другое ? iSCSI не использовал, в продакшн, но на тестах понравилось с ней работать. Вполне удобно отдавать на виртуалки логические устройства. В общем, видится вся городушка в виде сервера с хорошей дисковой системой и сетевым тиvмингом, который раздает smb, iscsi, nfs. Серверу память надо побольше под кэш, парочку процессоров было бы плюсом, сетевой тимминг тоже в плюс по любому. Можно оставить сервер как хранилище и до кучи нагрузить некоторыми службами, если кто-то плохо поведет себя на выбранных пролоколах или по сетке. Остается просчитать какая производительность, отзывчивость вам будет нужна и тд и тп и далее только по месту что-то исправлять
