Comments 141
У домашнего NAS есть огромная проблема, которая в конце концов ставит под сомнение саму идею — доступ извне — с нормальной скоростью, защитой и гарантированным каналом, не зависящим от прихоти вашего интернет-провайдера. Например, апстрим в больше чем 10Мбит получить вряд-ли удастся. С белым ай-пишником, проброской портов тоже проблемы.
В итоге домашний аналог облака не получается, как ни крути. Говорю, как владелец NAS с 5-летним стажем, потихоньку переходящий на Google.
Например, апстрим в больше чем 10Мбит получить вряд-ли удастся. С белым ай-пишником, проброской портов тоже проблемы.
Белый IP я покупаю. Об этом будет написано в следующей статье. Соответственно, с пробросом портов тоже проблем нет.
По скорости, могу немного прорекламировать ТТК (но не по удобству подключения услуг): проблем нет.
В крайнем случае, с провайдером возможно заключить SLA (но, скорее всего, это будет отдельная услуга).
В итоге домашний аналог облака не получается, как ни крути. Говорю, как владелец NAS с 5-летним стажем, потихоньку переходящий на Google.
Можете подробнее расписать проблемы, которые у вас возникали и существуют?
Пока жил в одной квартире, был один провайдер. Белый ай-пи без проблем, скорость фиговая, но доступ есть.
Переехал в другую — там другой провайдер. IPv6. Белый IP не дают, зато скорость — 120мбит даунстрим и 10 апстрим. Вот вам и один прекрасный момент, когда доступ к ресурсам накрывается.
Еще раз — отдельная услуга за SLA, белый ай-пи, место для облачного бэкапа — все это за пару лет набегает на стоимость второго NASa. То есть домашний NAS получается дороже облачного, да еще и с проблемной настройкой.
Да мелочь этот белый айпи, забудьте про него. Лучше скажите, в каком пакете ваш провайдер предлагает ну хотя бы 10Мбит апстрим трафика? Так как с меньшей скоростью даже фотки на телефоне не удобно смотреть. И добавьте это к стоимости NAS.
Нет, ТТК.
С ТТК такого нет. Пока что нет.
И если вы храните только фоточки/видео, которые готовы показать всем, тут действительно NAS будет лишним.
Так пришло осознание, что на решение проблем с NAS я трачу больше нервов, чем получаю удовольствия.
Я посчитал экономическую часть: 15 т.р. безвентиляторный микро-системник на Corei3 U с поддержкой AES-NI и QSV, чтобы домашние видео открывались по 3G с перекодированием на лету. Два внешних диска по терабайту с USB 3.0 — 3,5 т.р. каждый. И белый IP по 150-300 руб/мес * 12 мес * ~5 лет = 9..18 т.р, итого 30-40 т.р. за 5 лет без учёта непредвиденных поломок, обслуживания, электроэнергии. За эти деньги можно пользоваться Яндекс.Диском 20 лет, если они не изменят ценовую политику.
Мои фоточки вижу только я и теоретически — ФСБ, а этих ребят я готов потерпеть. Гит у меня тоже на Яндексе, в виде папочек с номерами версий, поскольку программирую один. А из безвентиляторного микро-системника получился отличный десктоп, который можно не выключать 24/7. Даже игрушки тянет.
Мне было чутка стрёмно выставлять свой Nextcloud напрямую в интернет.
Да ну, вполне надёжная система. В конце концов, при желании возможно включить двуфакторную авторизацию и капчу.
Пользовался через VPN.
Это удобно, только если вы пользуетесь облаком один, либо можете перетащить на VPN всех, кто с этим облаком работает, помимо вас.
За эти деньги можно пользоваться Яндекс.Диском 20 лет, если они не изменят ценовую политику.
Всегда есть "если".
Гит у меня тоже на Яндексе, в виде папочек с номерами версий, поскольку программирую один.
Тогда уж лучше github/gitlab/bitbucket.
Мои фоточки вижу только я и теоретически — ФСБ, а этих ребят я готов потерпеть.
Навряд ли ваши фоточки их заинтересуют, если там нет какого-то очередного "запрещённого контента".
Но вопрос стоит немного по-другому. Не столь важно, готовы ли потерпеть их вы, сколь то, готовы ли они потерпеть вас.
Провайдеру за белый не плачу. Сервак валидирует ip, если попался серый — перегружает роутер. В основном не мешает, так как
Электричество выходит вовсе копеечное в условиях РФ.
Я прав?
Я думаю над такой альтернативой: в качестве «входной двери» использовать дешевый VPS, к которому NAS будет коннектиться через VPN (главное чтоб условия по траффику подходящие были — а уж с маршрутизацей даже самая слабая конфигурация из предлагаемых должна справиться).
Я не агитирую исключительно за «домашний NAS», потому что там есть иные причины потери данных.
Но «гибридный вариант», когда используются оба варианта, взаимодействуя друг с другом, я считаю наиболее оптимальным с точки зрения доступности данных.
Но вы и платите два раза, что для домашнего пользователя немного многовато.
«гибридный вариант» — это NAS + Google?
Насчёт Google: в любой момент доступ к вашим данным может оказаться потерянным, по различным, не зависящим от вас причинам.
Это уже давно не так. Практически на любом компе Гугл предлагает ставить синхронизационное приложение, которое синхронизирует локальную папку с облаком. В итоге может потеряться доступ через интернет, но данные сохранятся на локальных репликах.
Это как синхронизация контактов через Гугл. Есть он или нет, контакты на телефонах остаются.
Практически на любом компе Гугл предлагает ставить синхронизационное приложение, которое синхронизирует локальную папку с облаком. В итоге может потеряться доступ через интернет, но данные сохранятся на локальных репликах.
Это как синхронизация контактов через Гугл. Есть он или нет, контакты на телефонах остаются.
Это если у вас один компьютер и папка. В случае git репозиториев, необходимости точки синхронизации онлайн или сервиса для совместной работы, риск остаётся.
Да и хорошо, если исходные коды приложения открытые, иначе неизвестно, что вы запускаете у себя на машине.
Кроме того, в вашей папке останется только последняя копия данных, либо поверх неё нужно использовать систему контроля версий.
Со своим NAS всё намного гибче и, если вам действительно надо, вс намного гибче.
Вы можете сделать тоже самое, используя, например какой-нибудь Syncthing, либо поднять лёгкое облако Seafile, клиент которого будет выполнять шифрование прямо у вас на машине и сливать в личное облако накопившиеся изменения без вашего участия, либо поставить более тяжёлый NextCloud и синхронизировать самостоятельно.
И никакой провайдер вам тут не указ.
Два бакса у него стоит второй IP!!!
А вы попросите katzen померять скорость с каким-нибудь узлом за пределами Украины, вот и узнаете.
Железка покупалась около 5 лет назад за 12-14 тысяч рублей.
Вложить в него нужно не меньше куска + белый айпи + интернет + ИБП
Варианты из дохлых ноутбуков не рассматриваем — смысл наса в надежности, если она не нужна, то можно просто с собой таскать 2тб диск на усб 3.0 со всеми данными.
При этом onedrive на терабайт стоит 50 баксов в год — это столько же, сколько стоит один wd green на те же 1 тб (а их нужно хотя бы два)
Если вас не устраивает «вложить не меньше куска», то это действительно не то решение, которое вам подойдёт.
Для тех, кому это не препятствие, утверждение «домашний нас реально не нужен» звучит неубедительно.
Нормально изучить тему, обеспечить винтам хорошее питание и температурный режим, и всё будет ок. Не одним MTFB живём.
Домашний нас — не всегда исключительно хранилище бескрайне ценных данных. Для многих это 1-25% данных и остальное — шлак в виде торрентов.
Потому, вопрос риторический, без сопутствующих данных.
Лично мне хочется надёжности и, соответственно, хорошего и проверенного железа, пусть и не самого «передового».
Но это не для всех так.
Если вы посмотрите обзор, там я, в целом, был за Synology. Да, есть проблемы и недостатки. Но сборка своего NAS, начиная с железа, выгодна в достаточно узкой области, и надо понимать зачем вы это делаете перед тем, как начать.
У меня DS213+ c двумя винтами в RAID1. В домашней гигабитной сетке из того, на чем мог протестировать, скорости чтения/записи в районе 30Мбайт/с — ИМХО достаточно для всего.
Но как я уже писал, из-за ограничений провайдера, да и моих хотелок по Git, он все больше и больше становится простой файлопомойкой с соответствующим внешним видом, так как пылится по самое немогу.
Можно ли чуть подробнее вот этот момент, плз? А то я вот как раз присматриваюсь.
Текущая цена какая-то странная, когда они появились на рынке, цена была куда адекватнее, а сейчас брать за 32-34к это я бы не стал.
По заявкам приверженцем, он я его включил в обзор. Да, неплохая железка. Вполне годен для многих вещей.
Следствием из этого, главной задачей построения данного NAS стало обеспечение точки синхронизации в виде системы управления Git репозиториями
Вынесу в отдельную ветку.
Подождите, Git, Git — это ж для работы, верно? Не могу себе вообразить, чтобы домохозяйке или обыкновенному юзеру был нужен Git.
Так вот у меня есть Git. На Atlassian Bitbucket, за 10 баксов в месяц и с бесплатной интеграцией в JIRA для баг-трекинга. На нем у меня крутятся и свои и фрилансерские проекты. Причем хочу — даю доступ к репо заказчику, хочу — подключаю сторонних разработчиков, с которыми я познакомился в интернете и коммитим вместе. А хочу — и удаляю этих юзверей нафиг.
Давал бы я таким же образом доступ к своему NAS? Да мне даже страшно ссылку на его домен давать, мало ли что какому-нибудь бывшему юзеру в голову взбредет, если он на меня обидится.
Как вы предлагаете решать эти вопросы?
Подождите, Git, Git — это ж для работы, верно? Не могу себе вообразить, чтобы домохозяйке или обыкновенному юзеру был нужен Git.
Ну представьте, что домохозяйка пописывает на досуге софт для автоматизации кухни и коммитит в гит.
Так вот у меня есть Git. На Atlassian Bitbucket, за 10 баксов в месяц и с бесплатной интеграцией в JIRA для баг-трекинга. На нем у меня крутятся и свои и фрилансерские проекты.
Ну и у меня есть репозиторий на гитхабе. И, если бы был нужен "приватный", я бы купил аккаунт или может использовал bitbucket. Но если я хочу иметь полный контроль над репозиторием, подниму свой.
Давал бы я таким же образом доступ к своему NAS? Да мне даже страшно ссылку на его домен давать, мало ли что какому-нибудь бывшему юзеру в голову взбредет, если он на меня обидится.
Как вы предлагаете решать эти вопросы?
- Не давать посторонним доступ, если вас это сильно волнует. В любом случае, давать доступ стоит только вменяемым людям, даже если это репозиторий на гитхабе.
- Если вас это не сильно волнует, обеспечить достаточную стойкость к взлому, так на всякий случай и сигнализацию о нарушениях. Как это сделать, зависит от модели нарушителя, которая соответствует вашему пользователю. Одно дело, если вы что-то не поделили с сотрудником Fancy Bear и он пытается вам отомстить, привлекая ресурсы группировки, и другое, если это студент-фрилансер.
- Не делать так, чтобы пользователи на вас обижались. В конце концов, если тот, с кем вы работали, очень сильно расстроится и у него будет сильное желание, он просто может найти, где вы живёте.
Ну представьте, что домохозяйка пописывает на досуге софт для автоматизации кухни и коммитит в гит.
Ну я тоже пописываю. И коммитю. Так ли сильно нужен мне этот контроль версий для домашней автоматизации, чтобы я плакал, если у меня закроется доступ в GIT и сохранится только последняя версия? Или может моим автоматизаторским кодом заинтересуются в ФСБ?
Но если я хочу иметь полный контроль над репозиторием, подниму свой.
Так а в чем он заключается — этот полный контроль? Возможно нужен не полный контроль, а 100%-ная приватность? Так это не одно и то же.
- Не давать посторонним доступ...
Это напоминает инструкции для предохранения от венерических болезней — надеть презерватив и, главное, никаких половых контактов. А если надо? А если юзеры все вменяемые, но вот бац — и ссылка попала не в те руки и на ваш NAS посыпались DDoS атаки? Как вы можете быть уверены, что его защита выдержит? А при том, что на нем же еще лежит и архив фоток за последние 20 лет, страшно не будет?
К сожалению в вашем оглавлении о статьях цикла нет ни одной ссылки или даже упоминания о статье об обеспечении безопасности в случае домашнего NAS. Добавьте, но я боюсь, что анализ вызовет у вас головную боль. Одно только обеспечение безопасности при проброске портов на каком-нибудь говнороутере упирается в такой интересный квест...
Я про то что по сути linux-систем километр.
Да. И в данном случае был взят подходящий дистрибутив. Для которого есть система управления NAS в виде OMV (это .deb пакет).
В процессе возникновения задач, пришёл к мнению что сам по себе NAS это бесполезная штука в целом.
Бесполезная для кого и для каких задач?
В целом все NAS используют туже samba, тот же linux
Все используют эти технологии, либо другие. NAS инженерное решение. И когда возможно использовать существующую технологию, зачем изобретать новую? Кроме того, SAMBA — это интерфейс с внешним миром. Обычно внешний мир под устройство не переделывается.
но при этом по сути ос у них урезаны, как плюс удобно в браузере настройки тыкать.
Если полноценная ОС не требуется, и есть смысл ограничивать функционал, она урезается. Если же нужна полноценная ОС, никто не заставляет урезать. В моём случае, это обычный Debian Linux.
Минус ещё же, их цена, очень чувствительно отличается от простого мини-сервачка на том же простите за мат celerone, где полноценно можно поднять даже тот же серваковый debian, и настроить его в доль и поперёк как хочется.
Ну в заголовке статьи, как вы можете видеть, есть домашний мини-сервер, и грань между NAS и сервером весьма зыбкая (не имея ввиду "большие" системы).
Вывод в интернет посредством vpn через тот же ddns от no-ip, и ни каких заморочек с белым не белым адресом, тут уже даже по сути место не имеет важности.
Dynamic DNS вам никак не поможет преодолеть неконтролируемый вами NAT.
Для того и нужен белый IP. Чтобы к NAS обращаться снаружи.
Да, VPN может помочь. Но он не во всех случаях удобен (это явно не решение для сервера).
Ибо свой мини сервер лично на мой взгляд более актуален и гибок в планировании и добавлении новых задач, вплоть до потокового видео и автономности.
Посмотрите на список задач в статье: всё это есть.
SAMBA с внешкой не дружит, ибо собственно это служба «общения» пк именно в локальной сети.
Я имел ввиду, что SAMBA поддерживается многими устройствами, а локальная сеть — это среда внешняя по отношению к NAS.
Для того, чтобы что-то отдавать пользователю в Интернете мне не нужно поднимать VPN.
И по SAMBA из Интернета (через VPN) с NAS я, конечно же, не работаю, потому что для этого есть более удобные варианты.
А по поводу ddns, если есть возможность проброски портов, а по статье я так понимаю он есть, то очень легко ваш неконтролируемый NAT подружить с нужными вам девайсами в сети(есть опыт).
Возможность проброски есть всегда, это сделано на роутере, это мой NAT. Неконтролируемый NAT не мой, а провайдера. Когда провайдер предоставляет уникальный IP только внутри своей сети и целые регионы выходят в Интернет с одного IP.
Просто у меня сложилось впечатление, что это более сложный путь.
Да, он сложнее, но кроме задач есть и другие условия.
Возможность проброски есть всегда, это сделано на роутере, это мой NAT. Неконтролируемый NAT не мой, а провайдера. Когда провайдер предоставляет уникальный IP только внутри своей сети и целые регионы выходят в Интернет с одного IP.
О, вот так даже, я думал такого уже не существует. Тогда при таких условиях ясен выбор.
Белый адрес, это априори постоянный ип, собственно равносильные синонимы.
Белый адрес — это адрес не за NAT. Обычно он статический. Но технически он может быть динамическим, потому это не синонимы.
Вот тут то и вступает в силу ddns
Я знаю, что такое dyndns, только no-ip мне не нравится.
Но ровным счётом ни каких костылей, как говориться само работает.
Клиент, дёргающий API сервиса, даже в виде скрипта на роутере — это и есть костыль.
Пользователи и их количество не значат ни чего, адрес доменный с портом один для всех.
Что в моём случае не сработает, т.к. перенаправление на сервисы производится по доменному имени (см. статью).
Клиент, дёргающий API сервиса, даже в виде скрипта на роутере — это и есть костыль.
Кроме этого, можно подробней, что вы имели в виду?
Иногда частные адреса называют неанонсированными, внешние (так называемые «белые IP») — анонсированными.
Белый адрес это статика.
Да, это то, что написано по ссылке, которую я вам дал на Википедию. Зачем это цитировать?
Вы писали, что "Белый адрес, это априори постоянный ип, собственно равносильные синонимы."
Я вам показал, что это не так. Кроме того, если вы прочитаете статью до конца, найдёте явное противоречие вашему утверждению.
Кроме этого, можно подробней, что вы имели в виду?
У вас есть сервер, к которому технически никто не запрещает обращаться не только по доменному имени, но и по адресу. Но если адрес меняется, всё падает.
Для того, чтобы эту ситуацию обработать, есть ddns, однако "автоматика эта работает относительно долго, при смене адреса 10-15-20 минут в среднем нет доступа".
Собственно, это и есть костыль чистой воды. Вариант бюджетный и допустимый, в основном для физ. лиц. Однако, крайне сомнительный для применения организацией.
Белый адрес — это адрес не за NAT. Обычно он статический. Но технически он может быть динамическим, потому это не синонимы.
Вообще-то белый адрес, как раз «обычно» (то есть чаще всего), в условиях именно России, именно динамический, так сложилось «исторически».
Клиент, дёргающий API сервиса, даже в виде скрипта на роутере — это и есть костыль.
Эм… то есть подпрограмма уведомляющая DHCP-сервер о просбе выдать адрес — костыль? Кусок кода, не важно в виде чего, уведомляющий какой-либо сервер о появлении нового клиента — костыль? Как и скрипт aka «кусок кода», уведомляющий сервер о изменении адреса… Оррригинально. Хорошо, встречный вопрос — тогда, что «не костыль»?
при смене адреса 10-15-20 минут в среднем нет доступа".
Платный «тариф», теперь, а раньше это и в бесплатном варианте было, раз уж кто-то заикнулся об «организациях» (каким боком они сюда попали, х.з.) — подразумевает обновление с сильно меньшим сроком, вплоть до мгновенно или минуты.
Эм… то есть подпрограмма уведомляющая DHCP-сервер о просбе выдать адрес — костыль? Кусок кода, не важно в виде чего, уведомляющий какой-либо сервер о появлении нового клиента — костыль?
Нет. Имелось ввиду именно применение dyndns в данных конкретных условиях.
Вообще-то белый адрес, как раз «обычно» (то есть чаще всего), в условиях именно России, именно динамический, так сложилось «исторически».
В моём случае, всё-таки белый и статический.
Нет. Имелось ввиду именно применение dyndns в данных конкретных условиях.
Хорошо, а если ту же функцию будет выполнять закрытая от вашего доступа железяка?
В моём случае, всё-таки белый и статический.
«Обычно он статический» =/= «В моём случае»
Хорошо, а если ту же функцию будет выполнять закрытая от вашего доступа железяка?
В чём разница, если результат тот же?
Разница в непонимании, что вся система DNS работает так! Адреса не приколочены друг к другу. Отличие в том, что обновления происходят реже, но реже только глобальные! Мелкие же изменения происходят постоянно, примером — масса разных CDN и вообще всяких «распределённых сетей», и так далее, и так далее — в которых символьный адрес слабо привязан к цифровому.
Работает как? Каждый раз меняется адрес, и каждый раз DNS сервер ждёт 20 минут после того, как некто дёргает его API, а пользователи не могут привязаться по адресу к серверу?
Тогда dyndns не были бы отдельными сервисами.
В пределе, конечно, всё меняется, и так возможно сказать про всё, но от этого мало толку.
в которых символьный адрес слабо привязан к цифровому
Да, так работает спуфинг, а для того, чтобы его нельзя было реализовать, используют сертификаты и DNSSEC.
В данном же случае, лучше перечитайте обсуждение и не смешивайте использование динамического DNS в данном конкретном случае со "всей системой DNS".
Это похоже на придирки и бесполезный спор: в конце концов, если не хотите считать костылём, не считайте.
Вы назвали нормальный сервис с кучей разных возможностей — костылём. Вы, уже дважды, сказали про мифические «20 минут». Вы даже отрицаете наличие тех самых разных дополнительных возможностей, приписывая их, наверное, только обычным DNS.
Придирка к называнию «костылём» одного из замечательных сервисов :P
Месяц назад задался этим вопросом и собрал такую машину:
- Intel Core i7-8700K
- ASUS ROG Strix Z370-G Gaming (Wi-Fi AC)
- Corsair Vengeance LPX 2x16GB DDR4 PC4-24000
- Fractal Fractal Design Node 804
- Corsair RM850i 850W
- 2 * Noctua NF-F12 PWM
- Corsair Hydro Series H100i v2
- 2 * SSD Samsung 860 Evo 1TB MZ-76E1T0B (зеркалируемый cache)
- 4 * WD Red 8TB [WD80EFZX]
Туда накатил unraid, пробросил видеокарты (встроенную и валявшеюся gts 250) для OpenFLIXR через HDMI и виртуальной рабочей станции сообтвественно (работает через parsec)
Дополнительно завел нужные мне сервисы (через docker в unraid), облачное хранилище, видеонаблюдение, miio для "умного" дома и тд.
Если заменить видеокарту на более производительную — можно получить облачную игровую машину, а без нее — просто хорошая рабочая станция, к которой можно подключиться тонким клиентом (raspberry pi 3 или что-то на основе Intel Atom x5-Z8350 и ему подобным) из любой точки где есть интернет (и даже дома).
Пишите, это будет полезно.
Почему память не 3600? Хотя это на любителя.
Почему водянка, если уже все вроде сошлись во мнении что хороший кулер — лучше?
Ну и почему материнка -g, а не z?
Вопросы из опыта сборки и на днях тоже получу опыт пользования от этого :)
Про SSD — причин две: цена и задача.
В unRAID SSD-cache используется для нескольких задач:
- Хранение данных перед записью на HDD с parity check
- Хранение временных торрент файлов
- Храниние записей с камер внешнего видеонаблюдения (если ничего не произошло — удаляется по прошествии какого-то времени)
- Docker/Образы виртуальных машин
Для себя решил что объем важнее чем 3500 мб/сек — по сети я ограничен гигабитным ASUS-роутером (то есть больше 120 я заливать в любом случае не смогу), а внутри — я не делаю каких-то супер операций, требующих таких скоростей. В будущем, если такие задачи появятся — докуплю M.2 SSD PCIe x4 и заиспользую Unassigned Devices Plugin.
Про память.
В моем селе (Минск, Беларусь) очень сложно достать редкие комплектующие, я был бы рад купить память на Samsung B-Die но найти G.Skill планками по 16 гб не получилось, поэтому взял эту — как мне показалось с нормальными таймингами, скоростью и на Hynix Die
Про охлаждение
Если вы присмотритесь к корпусу — то там не так уж и много места и, как мне кажется, Noctua-DH15 туда попросту не войдет, а вот водянка на два 120мм — отлично крепится к верхушке корпуса и отлично справляется со своей задачей — особенно после замены штатных кулеров на те самые Noctua — тишина да благодать.
Про материнку не понял, STRIX -z не нашел. Но всякий случай отвечу — я длительно время искал материнскую плату со следующими характеристиками — Z370, HDMI 2.0 и 6+ SATA. Размером mATX — нет таких :)
Из похожих — EVGA Z370 Classified K но она на ATX (не входит в корпус, нужно брать кубического гиганта X5) и ASRock Fatal1ty Z370 Gaming-ITX/ac (всем хороша, и thunderbolt 3 есть и SATA 6 штук, но всего 32 гб оперативной памяти и ограничение mITX формата — всего один слот x16 — либо видеокарта, либо SAS контроллер)
Поэтому взял эту. Сейчас бы с wifi не брал ибо бесмысленно — не получилось заиспользовать в том виде в котором я хотел, но блютус есть — а с блютусом все становится лучше :)
Пока идея накатить на него гипервизор ESXi/Proxmox, поднять на нём машину на Windows, Hackintosh, XPEnology, и ещё какие виртуалки тренировочные.
И что б к нему можно было подключаться с любого компьютера в доме или даже извне, и, возможно, периодически какие игры запускать.
Так что ваш опыт очень интересно было бы почитать. Тем более, что набор софта в вашем списке для меня в диковинку.
2 * Noctua NF-F12 PWM
Corsair Hydro Series H100i v2
Неплохо вы заморочились с охлаждением, да и прочие комплектующие очень неплохие.
Собрать сервер можно из чего угодно, всё зависит от задач. Я начинал с обычного сетевого диска, а сейчас у меня полноценный DEV/Production сервер с торрентами, TimeMachine, VPN и всем, что только мне нужно. Единственная роль, которую он не играет совсем, это телевизор.
Если руки прям совсем не из жопы, то можно настроить любую ОС под свои нужды, даже FreeBSD, с которой лично я сбежал, ибо не видел ни одного плюса, кроме неоправданного геморроя. Все мануалы есть, настройка любого сервиса и его тюнинг не представляет особых проблем. Использование готовых ОС для NAS — это отличная идея. Меньше геморроя там, где он не нужен, и всё уже продумали за тебя. В моём случае, мне совсем не нужен GUI, достаточно shell. При том, что я никакой не хардкорный сисадмин.
В моей практике самой большой проблемой был медленно умирающий SATA-контроллер, который давал ошибки и тормозил систему. Следующей проблемой были кривые руки.
Собрать отличный домашний сервер на 6-8 дисков можно самому в пределах $500. Это будет максимально красивый, маленький и бесшумный корпус с водяным охлаждением, большой памятью, хорошей производительностью и UPS, который нужен для сохранения ваших RAID в целости при проблемах с электричеством. Идеально: конечно, будет ещё добавить IP-KVM (+$150), потому что всякое бывает. Использование RAID крайне рекомендуется, ибо гражданские диски при перманентной работе в серверном режиме иногда вылетают. Впрочем, вылетают и хардкорные серверные диски за тонну денег. Бэкапы — наше всё.
Я бы всё-таки увеличил цену в 2-5 раз, потому что $500 — это какие-то старые цены, и если обзор посмотрите, то мало найдёте готовых решений по таких ценам.
1) % времени доступности вашего локального устройства и GIT сервиса в облаке, боюсь, будет разным. Там специально заточенные люди на дорогом железе поддерживают. А тут вся надежда на провайдера домашнего интернет и достаточно бюджетное железо
2) Уровень защищённости NAS, который только с облака бекапит и лишних портов-сервисов в мир не светит будет выше.
3) Канал нужен дороже, железа больше — сами пишите про 32 гига памяти и SAS диски.
Я понимаю, если бы надо было в мир экспонировать десятки терабайт — их в облако засунуть дорого, самому надо городить. Но что GIT что личное фото — это крохи. Если вы не профи фотограф.
Про seafile понимаю, симпатично. Я сам на nas4free поднимал, с майнтайнером пришлось списываться, он код прод FreeBSD подправил. Но я включил, убедился — и закрыл доступ. Не так мне надо свои фотки все видеть в сети. А те, что надо — копии отправлены в публичные облака.
% времени доступности вашего локального устройства и GIT сервиса в облаке, боюсь, будет разным. Там специально заточенные люди на дорогом железе поддерживают. А тут вся надежда на провайдера домашнего интернет и достаточно бюджетное железо
По сравнению с облачными сервисами, несомненно, — бюджетное.
Однако, вполне надёжное по сравнению с обычным "домашним".
Кроме того, в облачных сервисах чаще всего надёжность достигается не путём повышения надёжности железа и покупки самого дорогого, а путём его горячего резервирования, чего я себе, конечно, позволить не могу.
2) Уровень защищённости NAS, который только с облака бекапит и лишних портов-сервисов в мир не светит будет выше.
Тогда я получаю не NAS, а бэкапилку. И не могу использовать его сервисы. Значит, всё, что мне остаётся — пользоваться тем, что предоставляет облачный провайдер.
И вы забыли про самый главный момент: облачному провайдеру нельзя доверять. Если вы бэкапите данные с NAS, их возможно шифровать. В случае бэкапа на NAS из облака, у облачного провайдера всё хранится в открытом виде. Либо, вы используете шифрование на клиенте, при работе с облачным провайдером, что тоже несёт дополнительные сложности (и структура каталогов там, как правило, остаётся).
3) Канал нужен дороже, железа больше — сами пишите про 32 гига памяти и SAS диски.
SAS больше для надёжности, а 32 гига — на вырост, сейчас у меня 16 и хватает.
Я понимаю, если бы надо было в мир экспонировать десятки терабайт — их в облако засунуть дорого, самому надо городить. Но что GIT что личное фото — это крохи. Если вы не профи фотограф.
Так и NAS, в данном случае, не такой, чтобы с него возможно было непрерывно терабайты за минуты качать.
Да и не фоточками едиными.
Вы забыли ещё несколько вещей:
- NAS или сервер. Он обеспечивает несколько больше, чем просто хранение и предоставление доступа к данным. Это, в том числе, сервер.
- Облако вам даёт сервис, там вы "читатель": платите деньги — получаете результат. С такой позиции гораздо лучше купить готовый NAS и реализовать одну из схем. В данном случае, ещё должно иметься желание самому собрать и сделать, что важно.
- Облако может весело закрыться вместе с датацентром, как например было с ifolder (файлообменник, но суть та же).
- Облако может резко поменять политику и оплату. "Железное решение" всегда остаётся железным. Есть устройство, которое может сломаться, которое возможно починить. Но сюрпризов оно, если за ним следить не принесёт. В отличие от внешнего сервиса, который вы не контролируете. В таком случае, если NAS у вас бэкапилка, а рабочие процессы заточены на конкретного облачного провайдера, придётся всё переделывать.
P.S.:
От Seafile отказался в пользу NextCloud.
– если мы серьезно рассчитываем на него как на работающий инструмент, а не просто пытаемся надежно хранить то надо всего иметь дома «холодную» копию, чтобы можно было быстро заменить вышедшую из строя компоненту или все устройство сразу, если случилось ЧП. В идеале необходимо для него обеспечить надежную физическую защиту, особенно если дома есть дети или подростки.
– нужно проводить регулярные регламентные работы для предотвращения сбоев и повышения уровня безопасности. В частности, проверять восстановление бекапа, чистить пыль, проверять работу механических систем, UPS, заменять даже работающие системы (вентиляцию, жесткий диск, аккумулятор UPS), если прошел регламентный срок. Потому что иначе вы можете оказаться в командировке или на отдыхе, устройство накроется, а вы ничего сделать не сможете. Регламенты нужно разработать под вашу конкретную конструкцию, и им жестко следовать. Обновлять «живую» систему нельзя: надо обновить копию, задокументировать процесс, погонять, убедиться, что все работает, и только после этого делать все то же на живой. В общем, все как делают сисадмины в приличных компаниях.
– Рано или поздно придется делать апгрейд, иначе при очередной поломке вы банально не сможете купить сломавшуюся компоненту (память, жесткий диск, и т.д.). Я думаю, лет через 5-6.
– должен быть альтернативный канал удаленного доступа на случай, если что-то отвалилось, а вас нет дома.
В облачных вариантах есть свои риски, конечно. Но и у вас они есть, просто другие. В целом, если вы хотите, чтобы все было хорошо, то к своей системе надо относиться как к системе, за которую вы получаете деньги. Только тогда она действительно будет хорошо работать. Вопрос в том, кому это реально надо?
Информативный комментарий.
Обновлять «живую» систему нельзя: надо обновить копию, задокументировать процесс, погонять, убедиться, что все работает, и только после этого делать все то же на живой. В общем, все как делают сисадмины в приличных компаниях.
Это не вполне так. Есть "SLA", и не обязательно, что я предполагаю работу 24x7x365.
При этом, я могу свести к минимуму риски длительной потери работоспособности системы другими методами, например в случае ZFS, у меня есть снэпшоты и загрузочная флешка, так что я всегда могу откатиться к состоянию до обновления.
Рано или поздно придется делать апгрейд, иначе при очередной поломке вы банально не сможете купить сломавшуюся компоненту (память, жесткий диск, и т.д.). Я думаю, лет через 5-6.
На лет 5-6 (или чуть больше) оно и рассчитано.
если мы серьезно рассчитываем на него как на работающий инструмент, а не просто пытаемся надежно хранить то надо всего иметь дома «холодную» копию, чтобы можно было быстро заменить вышедшую из строя компоненту или все устройство сразу, если случилось ЧП.
Замена всего устройства не предполагается, потому что есть такое ограничение, как бюджет.
Замечу, что в случае серверов, не обязательно проводить регулярные замены по регламенту. Это идеальный вариант, но предполагает и большие затраты. Существуют варианты, когда оборудование работает в резерве (горячем или холодном), а замена производится по факту выхода из строя.
Как вы сами заметили, требуется заменять, в основном, компоненты, содержащие движущиеся части: диски и вентиляторы. Плюс, компоненты хранения, например SSD и те же диски, и аккумуляторы.
Их замена не представляет сложности, и то, что они рано или поздно выйдут из строя, предполагается.
ИБП следит за ёмкостью аккумулятора, диски и SSD находятся в резерве (SSD в зеркале, кроме не критичного для кэша, диски в RAIDZ), вентиляторов используется несколько, и также организован мониторинг.
В облачных вариантах есть свои риски, конечно. Но и у вас они есть, просто другие. В целом, если вы хотите, чтобы все было хорошо, то к своей системе надо относиться как к системе, за которую вы получаете деньги. Только тогда она действительно будет хорошо работать.
Ну естественно: везде свои плюсы, свои минусы. И без сомнения, некоторые риски приходится осознанно принимать.
Только гибридный вариант никто же не отменял. Я могу использовать NAS, как основной, и при этом, дублировать особенно критичные данные в облачные хранилища. Также, частично данные продублированы на стационарной рабочей машине и на мобильном ПК, который, если я отсутствую, находится со мной, т.е. физически удалён от NAS.
Вопрос в том, кому это реально надо?
Мне.
Это не вполне так. Есть «SLA», и не обязательно, что я предполагаю работу 24x7x365.
В любом случае, вы берете себя на работу в качестве семейного админа (если все это для семьи, а не только для себя). И напряг с SLA какой-никакой при этом возникает: вы выделили пару часов на вечер, что-то пошло не так, и объем проблемы вырос, и теперь надо решать между восстановлением и продолжением процесса, так как надо не только «откатить», но и выяснить, что пошло не так, а без «трупа» это не выяснить. А это означает, что ваша семья может на какое-то время остаться без любимых фильмов-фотографий-сервисов, к которым они привыкли.
В общем, я к тому, что
1. либо это «файлопомойка», которую не жалко,
2. либо это инструмент для работы, за которым тянется ответственность перед третьими сторонами, тогда SLA достаточно жесткий и нужны формальные регламенты,
3. либо это важное для семьи хранилище, тогда нужен консервативный подход к данным и управление процессом заполнения этими данными, чтобы ситуация не пришла быстро в п. 1,
4. либо это все вместе, и тогда у вас полный хаос, но когда есть возможность и нет контроля, то к этому обычно и сводится.
И все решения нужно принимать исходя из этого базового выбора. По моему опыту, многие осознанно заводят себе разные облачные хранилища под разные задачи.
Так я и говорю: SLA. Причём, он может не ограничиваться 4 пунктами, которые вы перечислили.
В данном случае, это что-то между пунктом 2 и 3, а "помоек" я стараюсь избегать: сложно контролировать и потом всё-равно надо разбирать.
А это означает, что ваша семья может на какое-то время остаться без любимых фильмов-фотографий-сервисов, к которым они привыкли.
Да, этот риск я принимаю. При разумном времени. Как факт: за то не очень долгое время, пока я эксплуатирую данную систему, поломки ограничивались единичным сервисом (как правило, это облако, после обновления) и чинились в течении нескольких часов.
теперь надо решать между восстановлением и продолжением процесса, так как надо не только «откатить», но и выяснить, что пошло не так, а без «трупа» это не выяснить
Часто это даже "с трупом" не так просто выяснить. Но да, конечно, если возможность прогнать на аналогичной системе есть, это надёжнее, тут не поспоришь. За счёт двукратного увеличения бюджета.
Просто складывается ощущение о навязчивой идея о том, что данные могут потеряться или быть недоступным какое-то время и/или требования к содержанию их в абсолютном порядке…
Вот насчёт абсолютного порядка — это то, к чему надо стремиться, потому что иначе помойка из данных станет нарастать, и потом в ней уже тяжело будет разобраться.
SLA, «семья может на какое-то время остаться без любимых фильмов-фотографий-сервисов, к которым они привыкли» и пр. И что? Ну остались, дальше то что? В чем проблема?
Для меня нет проблемы, я же говорю: этот риск я принимаю, потому что не ахти какие убытки (если в разумных пределах, конечно).
Остальные прекрасно переживут, и не такое постоянно случается — это же не бизнес с 99,999% гарантии доступности. Ну пошли, купили новую детальку, данные завели и все побежало дальше.
Ну да.
А где здесь ОКР?
Цикл статей: построение защищённого NAS, либо домашнего мини-сервера