Я устанавливаю свежий Ubuntu на наш лабораторный сервер. У нас есть множество массивных геномов, к которым должен получить доступ пользователь www-данных Apache. В настоящее время я сделал резервную копию всех данных на внешних дисках. Моя цель - иметь свежий Ubuntu, устанавливать на него новые веб-приложения, а затем импортировать утерянные старые данные, чтобы Apache обслуживал их пользователей, использующих эти новые приложения. Пользователи также загружали файлы. Приоритет состоит в том, чтобы упростить задачу, чтобы новый будущий системный администратор мог легко понять, как все работает на сервере. Мой текущий план:
1) Попросите сотрудника лаборатории (я вне штата) записать компакт-диск Ubuntu ISO, загрузить с него машину и выполнить базовая установка ubuntu, настройте мне доступ по SSH. Она переформатирует внутренний диск, за исключением папки / home, которая находится в отдельном разделе.
2) Перенести пользователей из старой установки; вручную очистить ненужные данные из папки / home (старая). Замените им новую / домашнюю папку.
3) Установите LAMP, веб-приложения и другое необходимое программное обеспечение.
4) Создайте папку / home / user / webdata, дайте пользователю Apache все права на нее. Внутри него создайте папку upload /, в которую пользователи сайта будут загружать файлы. Рядом с ним будет папка genomes /, содержащая символические ссылки на геномы, физически расположенные на внешнем диске. Apache будет предоставлять пользователям геномы из этой папки.
5) Настройте автоматическое резервное копирование / home / user / webdata / и разместите его в сети.
У меня нет опыта системного администрирования, поэтому у меня есть следующие сомнения:
a) Является ли хранение данных, как описано в шаге 4, чем-то хуже? Каким будет наиболее распространенный и эффективный способ хранения и обслуживания больших геномов и пользовательских загрузок? Должен ли я вместо этого разместить эту папку webdata / в / var / www / html? Или мне вообще не следует использовать символические ссылки и хранить геномы на внутреннем диске (в / home или / var)? Одна из причин, по которой мне не нравится это в / var, заключается в том, что хранить все в / home было бы просто и безопасно.
б) Можно ли изменить или добавить какие-либо другие шаги, чтобы сделать процесс более безопасным и профессиональным?
Большое спасибо за поддержку и дайте мне знать, если я должен предоставить дополнительную информацию.
Для меня файловая структура, состоящая из папки загрузок и папки геномов, звучит довольно стандартно, исходя из настроенных мной веб-приложений.
Это действительно ориентированная на системного администратора перспектива, но для меня, хотя организация файловых структур важна с точки зрения программного обеспечения / приложений, физическая настройка будет иметь большее влияние на избыточность, надежность и производительность - вещи, которые я мог бы включить при оценке "профессионализма" "установки.
Некоторые рекомендации, которые у меня могут быть:
1.) Купите небольшой NAS, если можете. Внешние диски не имеют избыточности, и скорости могут отличаться, особенно если у вас есть несколько пользователей, читающих / записывающих данные на один и тот же диск.
2.) Рассмотрите возможность использования точек монтирования для внешних подключенных данных и сразу укажите Apache. Если вы придерживаетесь структуры геномов / загрузок, вы можете подумать о подключении внешнего хранилища прямо к этим папкам или символической ссылке на общие ресурсы в каталоге / mnt.
3.) Действительно учитывайте операции чтения и записи и количество обслуживаемых вами пользователей. Если гномы большие и у вас будет много длинных последовательных операций чтения, поместите эти данные на отдельный том / набор дисков, сохраняя их отдельно от папки «Загрузки», более ориентированной на запись. Если вам нужно придерживаться одного диска или нескольких отдельных дисков, вы можете разделить данные на отдельные диски, поместив данные генома вместе на один набор дисков и загрузив на другой.
Как говорит Джон, с точки зрения системного администратора физическая настройка более важна, чем «организация» файлов и папок, потому что она оказывает наибольшее влияние на то, что заботит системных администраторов: надежность, производительность, масштабируемость, управляемость, мониторинг, избыточность. , DR / резервное копирование и т. Д.
Идея «правильно» настроить что-то и перенести пользователей туда - хорошая идея. Первое, что я сделаю, - это попытаюсь получить данные на массиве RAID, чтобы вы не потеряли данные и не простояли из-за неизбежного выхода из строя диска. Я сторонник аппаратного RAID, но программный RAID в Linux тоже не совсем ужасен - вы хотите добавить некоторый уровень избыточности на уровне сервера и улучшить время безотказной работы. (И, говоря о времени безотказной работы, я надеюсь, что этот сервер питает ИБП ...)
Затем я бы настроил какой-то дополнительный сервер для этой функции. (В порядке предпочтения) я бы попытался настроить его как кластер, [звучит, когда клиент сталкивается или оказывает влияние] или аварийное переключение, или даже сервер горячего резервирования. (Сервер, который готов и ожидает ввода в эксплуатацию, если / когда исходный умрет). Наличие избыточности данных не поможет, если блок питания перестанет работать, или ваша материнская плата закорочена и т. Д.
Наконец, решение для резервного копирования, которое будет широко варьироваться в зависимости от ваших потребностей и ограничений. Если вы можете настроить резервное копирование на ленту или с диска на диск в массиве, достаточно большом, чтобы обеспечить разумный срок хранения данных, это прекрасно. В противном случае лучше, чем ничего, даже небольшая система NAS потребительского класса. В худшем случае, в ситуациях без бюджета я хранил резервные копии важных серверов на диске моей рабочей станции, внешних USB-накопителях потребительского уровня и даже на шпинделях DVD-R. Важно убедиться, что у вас есть определенный уровень хранения данных. Наличие нетронутых резервных копий, сделанных накануне вечером, бесполезно, если вы обнаружите повреждение данных, начиная с прошлой недели, или если вы получили root-права месяц назад.