У меня появился «домашний сервер» на Linux всего через несколько лет, как мне купили компьютер. Сейчас, с того момента прошло уже более пятнадцати лет и большинство этого времени у меня был какой-то второй дополнительный компьютер дома. Однажды, когда пришла пора его обновлять, я задумался: а зачем мне отдельный роутер, если у меня и так уже есть свободный компьютер? Ведь тогда давно, в нулевые, для многих это была стандартная конфигурация.
Действительно: сегодня для этого можно завести отдельную виртуалку, пробросить туда USB или PCI карту Wi-Fi. А в качестве ОС можно одним махом использовать MikroTik RouterOS, получая за небольшие деньги ПО enterprise уровня.
Сложно недооценивать пользу онлайновых пакетов офисных приложений наподобие Google Docs и облачных хранилищ в жизни технически ориентированных людей (tech-oriented people). Технологии получили настолько широкое распространение, что даже компания Microsoft, уже длительное время доминирующая на рынке офисных приложений, в последнее время сосредоточилась на разработке веб-приложения Office 365 и убеждении пользователей перейти на подписную модель использования собственных сервисов. Тех, кого интересует процесс установки и настройки собственного хранилища приглашаем под кат.
Пользовательская рабочая станция — самое уязвимое место инфраструктуры по части информационной безопасности. Пользователям может прийти на рабочую почту письмо вроде бы из безопасного источника, но со ссылкой на заражённый сайт. Возможно, кто-то скачает полезную для работы утилиту из неизвестно какого места. Да можно придумать не один десяток кейсов, как через пользователей вредоносное ПО может внедриться на внутрикорпоративные ресурсы. Поэтому рабочие станции требуют повышенного внимания, и в статье мы расскажем, откуда и какие события брать для отслеживания атак.
О чем мы расскажем:
Как быстро развернуть общее хранилище для двух серверов на базе решений drbd+ocfs2.
Для кого это будет полезно:
Туториал станет полезен системным администраторам и всем, кто выбирает способ реализации хранилища или хотят попробовать решение.
От каких решений мы отказались и почему
Часто мы сталкиваемся с ситуацией, когда нам нужно реализовать на небольшом web-кластере общее хранилище с хорошей производительностью на чтение — запись. Мы пробовали различные варианты реализации общего хранилища для наших проектов, но мало что было способно удовлетворить нас сразу по нескольким показателям. Сейчас расскажем, почему.
Glusterfs не устроил нас производительностью на чтение и запись, возникали проблемы с одновременным чтением большого количества файлов, была высокая нагрузка на CPU. Проблему с чтением файлов можно было решить, обращаясь за ними напрямую в brick-и, но это не всегда применимо и в целом неправильно.
Ceph не понравился избыточной сложностью, которая может быть вредна на проектах с 2-4 серверами, особенно, если проект впоследствии обслуживают. Опять же, имеются серьезные ограничения по производительности, вынуждающие строить отдельные storage кластеры, как и с glusterfs.
Использование одного nfs сервера для реализации общего хранилища вызывает вопросы в плане отказоустойчивости.
s3 — отличное популярное решение для некоторого круга задач, но это и не файловая система, что сужает область применения.
