Здравствуйте. Имеется такая схема:
Всего 5 серверов, из них один "главный" (перекачивает файлы со своей папки на остальные 4 сервера с помощью rsync и scp). Для того, чтобы присоединиться по SSH к нужному серверу, нужно сгенерировать ключи для него.
Возникла следующая задача: на основе статистики перемещать файлы с одного сервера на другой в зависимости от факторов. Как я понял, нужно будет каждый сервер связывать с другим, итого много вариантов для указания ключей. Можно ли обойтись "малой кровью"? К примеру, при увеличении количества серверов, чтобы постоянно не генерить ключи? Спасибо.
А для чего такая возня с файлами? Может быть просто поставить распределенное хранилище типа S3 , например на базе ceph? Как раз при добавлении сервера добавится и общей емкости, да и настраивать где какие пулы лежат, можно очень гибко.
Алексей Черемисин: хм, впервые слышу о таком. Первое впечатление о ceph при прочтении статьи на хабре хорошее) Правда она 2013 года, и описывали там некоторые баги. Просто, в данный момент, выбор серверов для хранения осуществляется обычной sql выборкой. Вообще как происходит: на сайте добавляется пост, с помощью gearman отправляется запрос в хранилище с данными (основное, где лежат все файлы), и хранилище уже пересылает файлы на основные файловые хранилища, к которым потом осуществляется доступ пользователей. Костыль на костыле, но работает. Такое можно сделать с помощью ceph?
Дмитрий: Все достаточно просто, разворачиваем ceph на нескольких серверах с выделенными дисками (очень желательно) и выделенной сетевухой для ceph (очень очень желательно), устанавливаем на каждом сервере (можно на одном, двух трех, далее везде) radosgw (гейтвей для S3), в DNS (для roundrobin) заносим все сервера с radosgw, работаем с данными через любого REST клиента S3! Данные между серверами сами распределяются либо автоматически, либо как настроишь. У меня 100 терабайт кластер ceph (6 серверов и две полки), правда radosgw не пользуем, но пробовали и тестировали.
Дмитрий: В общем случае будет распределенное пространство из всех дисков (тех, которые выделили под ceph) всех серверов с failover, резервированием, автоматическим восстановлением и разными плюшками типа снапшотов. Дополнительно можно ceph rdb использовать как пространство для дисков виртуалок через libvirt например.
Алексей Черемисин: спасибо) Ну у меня 5 серверов, в каждом по 3 диска (один под систему) по 1тб. Этого, коненчо, много, у меня нет столько данных, просто на каждом из серверов пропуская всего 250мбит, одна сетевуха. Поэтому приходится создавать копии одного и того же ролика 2 раза и хранить на разных серверах для отказоустойчивости. Вы написали много непонятных для меня слов, но думаю стоит протестировать и попробовать) Сейчас на стадии разбора конфига. Просто я написал похожую систему распределения, но она не позволяет мне ничего с ней делать так сказать. Пришлось бы писать дополнительный модуль, который бы распределял видео по серверам. Получается, на одном сервере 1000 видео, на другом 300 и т.д, т.е. просто по условию стоит, какой из серверов выбирать. Интересно, как потом интегрировать её) Видел мельком, что есть php вариант коннекта и удаления файлов. А можно ли закачивать, к примеру, с файлового хранилища файл и распределять его по другим серверам?
Алексей Черемисин: и ещё такой вопрос: обязательно ли делать папку для монтирования /var/lib/ceph/osd/* ? Могу ли использовать /home/disk1 /home/disk2 ?
Первое, обязательно (!!!) ставьте под ceph выделенные ethernet-карты - это не так дорого. Соответственно в каждом сервере должно быть два адаптера как минимум, один для публичной сети, второй для ceph.
Да, можно использовать и /home/disk1 /home/disk2, только зачем? Потом сами запутаетесь, да и скрипты могут сбоить, вы же все равно эти диски под ceph отдадите.
Третье - с файлами напрямую работать не получится - это не файловая система! Работать придется через API S3 (или swift), ну или ставить дополнительно cephfs (я его не тестировал). Файлы придется заливать вручную, написав соответствующий скрипт. В вашем случае - рассматривайте ceph как распределенную базу данных с с доступом к объектам (файлам) через S3/Swift.
Что делает ceph, он копирует куски объекта (файла) на несколько серверов (обычно два или три), соответственно файл будет "размазан" по нескольким серверам в нескольких копиях. При обращении к объекту, его куски будут тянуться с нескольких серверов одновременно, при этом, так как объект лежит в нескольких копиях, то можно просто выключить один сервер - это ни на что не повлияет.
Есть еще cehfs, но мы ее не пользуем, может быть на видео она покажет хорошую производительность, тогда не придется вообще заморачиваться, подмонтировал раздел cephfs, и просто работаешь с файлами.
Алексей Черемисин: мне было бы удобнее работать, конечно, с автоматической системой, а именно: к примеру, как у меня сейчас:
1) добавляют фильм, запрос идёт с данными в большое хранилище файлов (видео парсятся именно на этот сервер). Там по крону стоит обработка этих задач. В данных уже указано, на какие сервера копировать видео.
2) Видео конвертируется.
3) Далее оно копируется на заданные 2 сервера, удаляется с источника, отправляется запрос назад с указанием id этих двух видео, и оно опубликовывается. Костыль, но работает) Руками добавлять сотни видео по несколько гиг - уж очень жестко)
Дмитрий: Не настаиваю, толкьо перелить файлы нужно будет один раз, далее просто работаем сразу через S3 API, ручками их туда загонять не нужно. Ну и cephfs попробуйте, это просто распределенная файловая система.
"Для того, чтобы присоединиться по SSH к нужному серверу, нужно сгенерировать ключи для него."
Не для него, а для удаленного пользователя.
Вы можете сгенерировать одну пару ключей, и пользоваться той же самой парой для подключения ко всем серверам.
Приватный ключ на главном сервере, публичный ключ - на серверах к которым подключаться, у удаленного юзера.
ой же парой ключей можно пользоваться.
Создать везде пользователя с одинаковым логином(чтобы не путаться), положить каждому пользователю один и тот же приватный ключ, добавить всем пользователям один и тот же публичный ключ и все.
Saboteur: может это и неверно с точки зрения безопасности, но используется root для коннекта везде. Немного не понял вышенаписанную вами фразу. Получается, нужно на каждом сервере создать приватные и публичные ключи. Что куда копировать теперь?
Использование root вообще не очень хорошо с точки зрения безопасности.
Давайте так.
1. Не путаем ssh ключи самого хоста и ssh ключи пользователей. SSH ключи хоста создаются во время установки ОС (точнее во время настройки службы sshd), и используются для определения куда вы коннектитесь. Вы их видите, когда первый раз подключаетесь откуда-то к серверу и вам предлагает добавить этот сервер в список known servers. Добавили и забыли.
2. Чтобы пользователь мог подключиться на удаленный сервер без пароля делается так:
а) Создается пара ключей.
б) приватный ключ кладется в $HOME/.ssh/id_rsa
в) публичный ключ копируется на удаленный сервер в того пользователя, под которым вы будете подключаться на удаленный сервер (технически, публичный ключ добавляется в файл $HOME/.ssh/authorized_keys на удаленном сервере, и в этом файле их может быть много)
если у пользователя user1@localhost есть $HOME/.ssh/id_rsa (приватный ключ)
а у пользователя user1@remotehost есть $HOME/.ssh/authorized_keys с публичным ключом
то user1 может подключиться к user1@remotehost без пароля.
если не указывать пользователя удаленного сервера, используется текущий логин
то есть
user1> remsh user1@remotehost
равно
user1> remsh remotehost
Если вы хотите подключаться рутом, то тогда всем рутам нужно прописать приватный ключ и публичный ключ.
Я бы рекомендовал пользоваться не рутом, а отдельным пользователем.
Saboteur: Пользуюсь linux довольно давно, но в вопросе пользователей я до сих пор не разобрался, как и с их правами) Видимо потому, что я постоянно работаю с системой.
>>Если вы хотите подключаться рутом, то тогда всем рутам нужно прописать приватный ключ и публичный ключ. << То есть к одному из 5 серверов скинуть все приватные ключи и публичные остальных четырёх, верно понял? Вот на первом сервере сгенерировал ключи (ssh-keygen -t rsa), публичный ключ скопировал на вторую машину (и cat id_rsa.pub >> ~/.ssh/authorized_keys). А каким образом хранить множество приватных ключей (получается, на одном сервере, если он будет соединяться со всеми другими, нужно хранить 5 приватных ключей)? обычным cat соединять?
Дмитрий: генерируете пару приватный-публичный на машине с которой будете осуществлять коннект, далее с нее выполняете ssh-copy-id server.name && ssh-copy-id server2.name и так далее, тем самым копируете публичную часть на все машины и получаете возможность с этой машины на них ходить по ключу. Если с каких-то еще надо ходить на другие повторяете операцию на других. Не переносите секретный ключ на другие машины, генерируйте на каждой свой, что бы можно было убрать доступ у любой из машин простым удалением публичного ключа. Не используйте cat для записи в authorized_keys, ssh-copy-id добавит ключ корректно и поставит верные права(то есть 600) на файл, а то засунув при помощи ката вы потом будете пытаться понять почему не можете с ключом зайти, а дело будет в том, что по дефолту у вас 644, а такие права для authorized_keys недопустимы.
Дмитрий:
Приватные ключи хранятся в разных файлах. По умолчанию пытается использоваться приватный ключ из файла $HOME/.ssh/id_rsa, если вы используете одну и ту же пару ключей - этого достаточно.
Если вы хотите пользоваться разными ключами к разным серверам, нужно либо поднимать ssh_агент, который будет в памяти хранить несколько ключей и пробовать разные.
Либо настроить $HOME/.ssh/config, в котором прописать к какому серверу какой ключ предлагать
Например $HOME/.ssh/config может выглядеть так:
host server1.com
HostName server1.com
User user1
IdentityFile d:\ssh_keys\id_rsa_srv1
host server2.com
HostName server2.com
User megauser2
IdentityFile d:\ssh_keys\id_rsa_srv2
Средний
