Когда мы задумываемся над хранением для системного администрирования, мы сосредотачиваемся на стоимости, надёжности, доступности, производительности, масштабируемости, досягаемости и ёмкости. Когда речь заходит о хранилище, легко запутаться с таким количеством подвижных составляющих, и это создаёт риск того, что мы можем потерять представление о том, чего мы желаем достичь. При принятии всякого решения о хранении мы обязаны уделять внимание данным обстоятельствам. И самое главное, по всем этим факторам. Чрезвычайно заманчиво сосредоточиться лишь на нескольких, из- за чего мы теряем представление о полной картине.

В большинстве случаев, когда вы анализируете причины произошедшего с системами хранения, которые не соответствовали потребностям бизнеса, вы почти всегда обнаружите, что один или несколько из указанных обстоятельств были забыты на этапе проектирования. Очень соблазнительно сосредоточиться на одном или двух ключевых факторах и игнорировать прочие, но нам на самом деле необходимо удерживать внимание на всех из них для обеспечения успешного хранения.

Нам следует начать с разбивки каждого из обстоятельств по отдельности.

Может показаться, что никто не способен забывать о стоимости в качестве сомножителя в хранилище, но поверьте мне, это происходит, и происходит часто. Как правило, ИТ - это некая функция бизнеса, а все предприятия, по определению, занимаются зарабатыванием средств и сама стоимость обеспечения необходимой инфраструктуры всегда обязана учитываться в прибыли. Итак, по этой причине, ни одно из решений в ИТ (или где бы то ни было ещё в бизнесе) не должно приниматься без учёта затрат. Мы никогда не должны позволять забывать о стоимости или, что ещё хуже, позволять кому бы то ни было утверждать что стоимость не имеет значения, поскольку это никогда не может быть правдой и не имеет абсолютно никакого смысла. Стоимость может оказываться не самой главной задачей, а бюджетные ограничения могут оказываться гибкими, но стоимость всегда имеет значение.

Как правило, хранилище является одним из самых дорогостоящих компонентов производственной системы, поэтому мы склонны предполагать, что затраты являются более чувствительными при сделке с хранилищем, чем когда мы имеем дело с прочими частями физической системы, такими как ЦПУ и ОЗУ. Хранение также проще всего решить, просто вложив в него больше средств, а потому, раз это просто, многие люди при планировании аппаратных средств ошибаются в сторону надстройки. Конечно, мы всегда можем выполнить её пока мы достаточно осознаём свои потребности в хранении и то, как работает хранилище, причём оно будет работать не будучи чрезмерно дорогим. Но, естественно, трудно быть действенными системными администраторами когда мы неэффективны с точки зрения затрат - оба этих момента идут рука об руку.

Когда речь идёт о хранении, нет ничего более важного, чем долговеность: способность механизма хранения противостоять утрате данных. Долговечность является одной из двух сторон надёжности. Для большинства рабочих нагрузок и большинства сценариев систем долговечность перыше всего. Очень редко мы желаем хранить что- то, что мы не сможем надёжно получить, даже когда извлечение этого буде медленным, отложенным или дорогим. Таике понятия как доступность данных или производительность ничего не значат, когда сами даннык утрачены.

Долговечность также относится к данным, которые противодействуют повреждению или разрушению. В хранилище нам приходится беспокоиться о возможности потери целостности части своего набора данных, что может быть, а может и нет тем, что мы способны обнаруживать. Тот факт, что мы способны самостоятельно извлекать данные, вовсе не говорит о том, что извлекаемые нами данные являются именно такими, какими они должны быть. Повреждение данных может означать некий файл, который мы не имеем возможности более считывать, какую- то базу данных, к которой мы не способны больше получать доступ, операционную систему, которая более не запускается или, что ещё хуже, это даже может означать изменение некого числа в бухгалтерском приложении на другое, но допустимое, число, которое почти невозможно выявить.

Традиционно мы размышляем о надёжности данных в основном с точки зрения доступности своих данных в тот момент, когда пришло время их извлекать. Доступность часто именуют временем безотказной работы, и раз ваше хранилище недоступно, то и ваша рабочая нагрузка тем более. Тем самым, хотя доступность и уступает обычно долговечности, она по- прежнему чрезвычайно важна и выступает одной из двух ключевых сторон общей надёжности системы хранения.

Встречаются ситуации, когда доступность и производительность переплетаются. Могут иметь место случаи, когда производительность хранилища падает настолько, что данные фактически превращаются в недоступные. Рассмотрим душевую, в которой вода капает каждые несколько секунд, технически говоря, вода всё ещё имеется, но она не проходит по трубам достаточно быстро, чтобы ею можно было пользоваться.

Мы ещё слегка погрузимся в RAID, ведь доступность и производительность - хорошие примеры из реальной жизни. С большими массивами RAID 6 может возникать известная ситуация, когда один или два диска вышли из строя и были заменены, а массив подключён и пребывает в процессе активного восстановления (процесс, при котором отсутствующие сведения пересчитываются из метаданных). Именно это является достаточно распространённой ситуацией для системы RAID, которая будет перегруженной из- за количества обрабатываемых и записываемых данных, а в то время как наш получаемый в результате массив технически говоря включён и доступен, но настолько медленный, что его нельзя использовать каким бы то ни было осмысленным образом, а операционные системы или приложения, предпринимающие попытку его использования окажутся не только бесполезными по причине чрезвычайной медлительности, но даже способны выдавать ошибку, сообщая что их хранилище отключено по причине слишком длительного времени отклика. Если мы не будем аккуратны, доступность может превратиться в туманное понятие.

Когда речь заходит о компьютерах двадцать первого века, хранилище почти всегда является самым существенным узким местом в наших системах. ЦПУ и ОЗУ почти всегда обязаны ожидать хранилище, а не наоборот. Современное, применяющее твердотельные технологии хранилище для сокращения разрыва в производительности между системами хранения и прочими компонентами сделало многое, на величина разрыва всё ещё остаётся значительной.

Производительность может быть трудно измерять, поскольку существует множество вариантов взглянуть на неё, к тому же различные типы носителей хранения обладают тенденцией к очень различным характеристикам производительности. Существуют такие понятия как латентность (задержка, время перед тем как начнётся выборка данных), пропускная способность (также именуемая полосой пропускания, измеряемая значением скорости, с которой способны передаваться потоком данные), а также число операций ввода/ вывода в секунду, или IOPS (значение числа связанных с хранением действий, которые способны выполняться в каждый момент времени). Большинство людей представляют себе хранилище исключительно в терминах пропускной способности, однако традиционно IOPS выступают наиболее полезным измерением производительности для большинства рабочих нагрузок.

Всегда имеется соблазн свести обстоятельства к чему- то простому для понимания и сравнения. Однако если мы задумаемся об автомобилях, мы бы могли сравнить три транспортных средства: одно с быстрым ускорением, но с низкой максимальной скоростью, другое медленным ускорением и высокой максимальной скоростью и тягач с медленным ускорением и с низкой максимальной скоростью, но способным перевозить сразу много чего. Первая машина блистала бы, если бы нас заботила лишь латентность: время поступления самого первого пакета. Вторя машина бы сверкала, если бы мы заботились о том, как быстро можно перевезти небольшой груз с места на место. Это больше всего похоже на измерение IOPS. Прицеп тягача окажется непревзойдённым, если нас интересует сколько данных итого может быть передано между системами в процессе работы всей системы. Это наша пропускная способность или полоса пропускания. Что касается автомобилей, большинство людей представляют себе быструю машину, как о машине с наивысшей максимальной скоростью, но когда речь заходит о багаже, большинство людей задумываются о примере с тягачём с прицепом как о том, что они хотели бы измерить, а не о том, что представляется быстрым, когда они пользуются им. На самом деле производительность это вопрос точки зрения. Различные рабочие нагрузки воспринимают производительность по- разному.

К примеру, резервное копирование имеет дело с постоянными, линейными данными и получают наибольшую выгоды от систем хранения, спроектированных с учётом пропускной способности. Поэтому ленты настолько хорошо подходят для резервного копирования и потому старые оптические носители, такие как CD и DVD были допустимы. Но иные рабочие нагрузки, такие как базы данных, сильно зависят от IOPS и низкой латентности и мало выгоды получают от общей пропускной способности, а потому действительно выигрывают при твердотельном хранилище. Прочие рабочие нагрузки, такие как файловые серверы, зачастую нуждаются в сочетании производительности и отлично работают со шпиндельными жёсткими дисками. Для проектирования надлежащей системы хранения под её сопровождение вам надлежит знать свою рабочую нагрузку.

Производительность даже ещё более сложна, когда мы начинаем задумыватья о сопоставлении взрывных и устойчивых скоростей. Просто есть над чем задуматься и вы не можете сокращать этот процесс.

Ожидается, что развёртывание типичной физической системы в наши дни пребывает в эксплуатации от четырёх до восьми лет и, нередко, можно услышать, что системы применяются гораздо дольше. Проведите много времени работы в ИТ и вы, скорее всего, столкнётесь с системами, всё ещё включёнными и целиком критически важными в успешной компании, которые непрерывно применяются в течение двадцати и более лет! Поскольку ожидается, что система хранения будет иметь столь длительный срок службы, нам следует рассмотреть как такая система сможет расти или изменяться на протяжении этого потенциального периода времени.

Для большинства рабочих нагрузок требуется увеличение ёмкости с течением времени, а конструкция хранилища, которая способна расширять ёмкость по мере необходимости, может быть полезна как для защиты от неведомого, так и для того, чтобы мы имели возможность вкладывать минимальные первоначальные инвестиции и тратить большие средства только тогда, когда и если возникает потребность в дополнительной ёмкости. Некоторые системы хранения также могут масштабироваться в плане производительности. Это менее часто встречается и реже считается критически важным, но даже когда рабочая нагрузка лишь увеличивает потребности в ёмкости, вместо требования к производительности как таковой, сама по себе большая ёмкость способна гарантировать необходимость повышения производительности исключительно для таких задач, как резервное копирование, ибо большие ёмкости означают большую продолжительность выполнения резервного копирования и восстановления.

Теоретически, вы также можете обладать ситуацией, при которой необходимость для надёжности (долговечности, доступности или обеих) может требовать увеличения со временем. Это также может быть возможным, но, вероятно, будет более сложным.

Хранилища это область, в которой гибкость настройки конфигурации со временем часто является наиболее сложной, но и самой важной. Мы не всегда способны предвидеть какими будут потребности в будущем. Нам надлежит планировать всё что в наших силах для обеспечения гибкости, чтобы, когда это возможно, приспособляться.

Наконец, мы рассматриваем ёмкость, тот объём данных, который может храниться в системе. Ёмкость может казаться простой, но она способна сбивать с толку. Даже в простых дисковых массивах нам следует мыслить в терминах сырой ёмкости (суммы ёмкостей всех устройств) и получаемой в результате ёмкости (полезной ёмкости системы, к которой можно получать доступ для целей хранения). Многие системы хранения обладают избыточностью для обеспечения надёжности и производительности, причём это происходит за счёт потребляемой сырой ёмкости. Поэтому мы должны знать как наша конфигурация своего хранилища повлияет на окончательный результат. Администраторы хранилища будут говорить как о сырой, так и о полезной ёмкости.

Теперь, когда у нас хорошее представление в плане хранилищ, которые нам необходимо иметь в виду, мы можем углубиться в изучение того, как компоненты хранилища объединяются для создания корпоративных подсистем хранения.

В основе любого стандартного механизма хранения, с которыми мы столкнёмся сегодня, лежит понятие блочных устройств. Блочные устройства это устройства хранения данных, обеспечивающие энергонезависимое хранение данных, которые можно сохранять и извлекать в произвольном порядке. С практической точки зрения стандартное блочное устройство можно представлять в качестве жёсткого диска. Жёсткие диски являются прототипом блочного устройства и мы можем представлять себе любое иное блочное устройство как жёсткий диск. Мы также можем называть это реализацией интерфейса накопителя или проявлением (appearance).

Многие вещи являются блочными устройствами. Традиционные шпиндельные накопители, твердотельные накопители (SSD), гибкие диски, CD-ROM, DVD-ROM, ленточные накопители, диски оперативной памяти (RAM), массивы RAID и прочее, всё это блочные устройства. При рассмотрении компьютера, все эти устройства одно и тоже. Это упрощает работу системного администратора: всё построено на блочных устройствах.

С точке зрения системного администратора, мы часто просто ссылаемся на блочные устройства как на диски, потому как с точки зрения операционной системы мы не можем больше ничего говорить о таких устройствах и знаем только что мы имеем дело с блочным устройством. Такое блочное устройство может быть физическим диском, логическим диском, построенным поверх множества дисков, некую абстракцию, собранную поверх памяти, ленточный накопитель или удалённую систему, всё что угодно. Мы не можем сказать точно что это. Для нас это просто блочное устройство, а поскольку блочные устройства обычно представляют собой диски, мы называем их дисками. Это не обязательно в точности так, но это полезно.

Самый простой тип устройств блочного хранения это тот, который подключается к нашей системе. Мы знакомы с ними, например, в виде стандартных внутренних жёстких накопителей. Локальные блочные устройства обычно подключаются в наши дни посредством подключений SAS, SATA и NVMe. В недавнем прошлом стандартами были Параллельные SCSI (со временем именуемые просто SCSI) и Параллельные ATA (синоним PATA), просто именуемые со временем как ATA или IDE. Все эти технологии, а также некоторые менее известные, позволяют физическим блочным устройствам непосредственно подключаться к вычислительной системе.

Это локально подключённое хранилище, с которым мы и будем работать большую часть времени. И вообще, все блочные устройства должны быть где-то локально подключёнными для их применения. Так что эта технология всегда актуальна.

Локально подключаемые блочные устройства обладают множеством преимуществ перед своими альтернативами. Локальное подключение естественным образом даёт преимущество в производительности и надёжности: система проста настолько, насколько это возможно, а это означает что будет меньше сбоев. При прочих равных условиях простое выигрывает у сложного. Хранение - отличный тому пример. Меньшее число подвижных составляющих и более короткие пути подключения означают то, что мы получаем минимально возможную задержку, максимально возможную пропускную способность и высочайшую надёжность при минимальных затратах!

Естественно, локальное хранилище поставляется с некоторыми оговорками, иначе никто бы не предложил иной вариант. Основным недостатом локально подключаемого хранилища выступает гибкость. А именно, существует ряд ситуаций, которые локальное хранилище не способно обеспечить, а потому порой приходится выбирать альтернативные подходы.

Логичной альтернативой локально подключаемому устройству выступает удалённо подключаемое устройство, и хотя можно было бы предположить, что мы будем обращаться к такому типу блочных устройств подобным образом, это не так. Удалённо подключаемое устройство применяет для реализации концепции удалённости под такое хранилище пользуется сетевым протоколом, а сама сетевая среда, в которой осуществляет взаимодействие удалённое устройство, носит название Сети хранения данных (Storage Area Network) и по этой причине в общепринятом общении все удалённые блочные хранилища просто именуются SAN.

Технически говоря, Сеть хранения данных должна быть названием выделенной сетевой среды, которая применяется для несения в себе обмена блочного устройства и в очень технических кругах данный термин применяется именно так. Устройства в SAN могут быть непосредственными блочными устройствами, дисковыми массивами и прочими аналогичными устройствами блочного доступа в сетевой среде. Сама SAn это именно сетевая среда, а не та штука, которую вы покупаете.

Однако в обиходе любое обеспечивающее хранилище устройство реализует некий интерфейс блочного устройства и подключается в виде SAN к какой- то сетевой среде, а не напрямую к компьютеру. Вы ежедневно слышите это во фразах типа ты купил SAN?, нам необходим инженер SAN, я переговорил с производителем нашей SAN, следует ли нам обновлять свою SAN? и где наш SAN? Пройдите к своему ближайшему производителю ИТ оборудования и попросите его продать вам некую SAN и у них не будет сомнений, эта терминология настолько стандартна, что сто к одному будет то, что они полностью запутаются когда вы попробуете вести себя так, будто SAN это что угодно, но не аппаратное устройство, в котором вы размещаете жёсткие диски и которое подключено к сетевой среде кабелем какого- то вида.

По причине сложности, запутанности и боязни системы хранения, а также из-за того, что Сети хранения данных добавляют дополнительные уровни сложности в добавок к её основе, вся эта область стала рассматриваться в качестве чёрных ящиков, которые полны магии, причём терминология быстро устарела и большинство представлений о SAN стали базироваться на неверных представлениях и мифах. Распространённые мифы содержат в себе такие невероятные идеи, как то, что SAN не могут выходить из строя, что SAN быстрее такой же технологии без сетевого уровня, что SAN являются требованием для прочих технологий и так далее.

Мы можем быть более действенными системными администраторами только в том случае, когда понимаем как работает сама технология и избегаем поддаваться мифам (и маркетингу). К примеру, мы не можем проводить осмысленный анализ рисков или принимать решения о производительности когда мы рассматриваем устройство как волшебное и не учитываем его реальные очертания риска.

Теоретически, SAN это чрезвычайно простое понятие. Мы берём любое блочное устройство, будь то физическое устройство такое как реальный жёсткий диск, или некое более сложное понятие как какой- то массив устройств и встроенный протокол стандартного блочного устройства (такой как SCSI или ATA) и отправляем его поверх сетевого протокола (например TCP/IP, Ethernet или FiberChannel). Сам сетевой протокол действует до некоторой степени как простой туннель для предоставления блочного протокола на большие расстояния. Вот и всё что необходимо. В конце концов, это всё ещё просто некое устройство на основе SCSI или ATA, но теперь его можно применять на большом расстоянии.

Естественно, то что мы только что добавили слегка усложняет работу, а потому SAN автоматически становятся более уязвимыми нежели локальные хранилища. Сохраняются абсолютно все те риски, относящиеся к локальным хранилищам, а также любые сложности и риски, связанные с сетевым уровнем и сетевым оборудованием. Такие риски накапливаются. Кроме того, дополнительный сетевой уровень, обработка и расстояние должны увеличивать задержку транзакции данного хранилища.

По причине таких факторов основанные на SAN хранилища всегда медленнее и более хрупкие чем прочие идентичные локальные хранилища. Те самые факторы, которые большинство мифов применяло для продвижения SAN именно и выступают их слабыми местами.

Разумеется у самого подхода SAN имеются и свои сильные стороны, иначе она не имела бы смысла. SAN делает возможными три критически важные функции: расстояние, укрупнение и совместно применяемые подключения.

Расстояние может означать что угодно от нескольких дополнительных метров до всего мира. Естественно, при больших расстояниях увеличиваются задержки и, как правило, хранилище крайне чувствительно к задержке, а потому крайне редко бывает что удалённое блочное хранилище приносит пользу за пределами диапазона локального подключения. Когда вам необходимо передавать данные блочного хранилища через глобальную сетевую среду, вы, скорее всего, столкнётесь как минимум с вызывающими серьёзные проблемы производительности задержками и, как правило, остановитесь перед неприемлемыми ограничениями полосы пропускания. Предполагается, что типичное промышленное блочное хранилище обладает пропускной способностью в несколько ГБ/с (большая Б, а не мальенькая) и задержку менее миллисекунды, в то время как соединения глобальной сетевой среды редко достигают даже одного Гбит/с и даже наилучшие показатели задержки составляют несколько миллисекунд, если не более, и даже больше!

Традиционно уплотнение было главной ценностью SAN. Поскольку многие системы способны физически подключаться к одному массиву хранения поверх одной сетевой среде, впервые стало запросто инвестировать в единую дорогую систему хранения, которую можно было бы применять одновременно многими физически обособленными вычислительными системами. Само хранилище в таком устройстве будет нарезано и каждое подключённое к нему устройство будет наблюдать свою собственную уникальную часть хранилища.

 

Когда локальное хранилище не является локальным

При всех тех интерфейсах, абстракциях и неверной терминологии, которые зачастую присутствуют в ИТ, запросто утратить представление о том чо именно происходит в большинстве случаев. SAN являются одним из тех мест где происходит путаница, это обычное дело. Именно сама природа SAN состоит в том, чтобы получать находящееся далеко блочное устройство и делать так, чтобы применяющему его компьютеру оно представлялось локальным. Но этот компьютер также может взять нечто локальное и сделать так, чтобы оно представлялось локальным, хотя на самом деле оно удалённое. Что я только что сказал?

Наилучшим примером этого выступает внешнее USB жёсткое устройство. Мы все пользуемся ими; они очень распространены. Зайдите в любой местный магазин и купите его. Закажите его через Интернет. Наверняка у вас имеется пять штук таких на полке, о которых вы позабыли. USB- накопитель, хотя он и внешний, всё же локальный, так ведь?

Ладно, всё не так просто, так сказать. Естественно, они физически близки. Но с технической точки зрения удалённый означает, что нечто находится в сетевой среде, а локальное вне сети. Неважно насколько далеко находится нечто, именно сама сетевая сторона вопроса определяет локальные и удалённые устройства. В противном случае моё рабочее место в Техасе физически подключено к рабочему месту моего отца в Нью Йорке, потому как имеется последовательность кабелей по пути между ними.

Это представляет собой некую занимательную задачу, потому что как вы видите, USB это на самом деле очень простой сетевой протокол, также как и IEEE 1394 и Thunderbolt. Если вы физически проанализируете некий внешний диск, вы можете обнаружить это в работе. Они составлены из стандартных жёстких дисков, как правило, с интерфейсом SATA, и крошечного сетевого адаптера, который вставляет протокол SATA в сетевой протокол USB для отправки по сети (зачастую на расстояние всего в несколько футов).

USB и им подобные могут не выглядеть подобно сетевому протоколу, но на самом деле это так. Это сетевой протокол второго уровня, который соперничает с EThernet и способен подключать несколько устройств к нескольким компьютерам и даже может применять предметы, похожие на коммутаторы. Это реальная сетевая платформа, а потому внешние жёсткие диски, подключаемые через USB, на самом деле являются крошечными SAN! Трудно в это поверить, но это и в самом деле так. Считайте что мы взорвали вам мозг.

Будучи самой дорогостоящей частью большинства систем, хранилище снижает затраты на развёртывание новых физических вычислительных систем обладая способностью разделять и нарезать его. Например, жёсткие диски могут обладать размерами в 1 ТБ, однако одной системе может требоваться лишь 80 ГБ или 300ГБ или что-то ещё, а в случае с общей SAN сотни компьютеров способны совместно пользоваться одним массивом хранения, причём каждый применяет лишь то что требуется ему. Сегодня мы получаем большую часть такой эффективности за счёт локального хранилища с виртуализацией, но до того как виртуализация стала повсеместно доступной, лишь такие системы как SAN были способны обеспечивать подобную экономию средств. Таким образом, на заре существования SAN основное внимание уделялось экономии средств. Прочие функции, в действительности, появились позднее. Сегодня эта ценность в целом повернулась в обратном направлении, а потому обычно они более затратны чем локальные хранилища с избыточным выделением ресурсов, но в некоторых ситуациях всё ещё может иметь место.

Последней ценностью выступает совместное использование подключений. Именно тут два или более компьютеров выполняют доступ к одной и той же порции своего хранилища в том же самом устройстве - обозревают те же самые данные. Это может звучать слегка подобно обычному разделению файлов, но это не совсем так.

При совместном использовании файлов мы привыкли к компьютерам, обладающим интеллектуальным устройством контроля доступа, которое разрешает доступ к файлам. Что касается SAN, нам следует помнить, что это тупое блочное устройство, не обладающее собственной логикой. Применение SAN для подключения двух или более вычислительных систем к одному блочнму устройству означает, что каждый из компьютеров считает такое хранилище своей собственной, частной, полностью изолированной системой и ничего не знает о прочих системах, кторые также могут быть подключёнными к нему. Это может приводить к большому разнообразию проблем, от утраченных изменений до повреждений в файлах и разрушенных файловых систем. Естественно, имеются механизмы для создания совместно используемых пространств хранения, однако, по определению, они не реализованы SAN и должны предоставляться на более верхнем уровне самих вычислительных систем.

 

Совместно используемые подключения SCSI

В дни до появления SAN, или до того как SAN стали популярными и широко доступными, имелась ещё одна технология, позволяющая двум компьютерам совместно использовать один пул жёстких дисков: разделяемый SCSI.

При помощи данной технологии один ленточный кабель SCSI (обычно способный подключаться к восьми, шестнадцати и даже тридцати двум устройствам). Одно устройство должно быть контроллером, предположительно на материнской плате компьютера. Другие подключения были открыты для соединения. Но другой разъём можно было бы подключить и к другому контроллеру на отдельном компьютере, причём каждый из двух компьютеров мог бы наблюдать и получать доступ к одним и тем же дискам.

По причине ограниченй, связанных с необходимостью совместного применения одного ленточного кабеля между двумя физическими компьютерами, данный метод был отвратительно ограниченным и неудобным, но осуществимым. Основная ценность такого рода настройки состояла в том, чтобы допускать выход из строя одной вычислительной системе, в то время как другая берёт на себя управление, или же удваивать ресурсы ЦПУ и ОЗУ, выделяемые для одного набора данных помимо того, что моглло бы заключаться в одном корпусе сервера. Однако ограничения надёжности и производительности компонента хранения делали всю систему в целом менее практичной, а потому данный метод редко применялся в реальной ситуации. Но исторически это очень важно, потому как это основа современного общего блочного хранилища, именно это составило стандартные сведения при обучении системам в конце 1990-х годов, и это помогало визуализировать то, как SAN работает в наши дни - более элегантно, более гибко, но, в целом, это то же самое.

В наши дни самые крупные варианты применения подключений к разделяемому блочному хранилищу - это кластерные системы, которые предназначены для применения такого типа хранилища в качестве совместной поддержки под виртуализацию. Это было пиком моды в районе 2010 года, но с тех пор он уступил место иным подходам для удовлетворения подобных потребностей. Теперь это будет весьма специфичная архитектура варианта системы. Но, как мы вскоре увидим, применяемые тут технологии будут адаптированы под иные модели хранения.

В мире SAN присутствует большое число популярных технологий подключения. Существуют сверх простые транспорты SAN, настолько простые, что никто не признаёт их таковыми, включая USB, Thunderbolt и IEEE1394/ Fireware. Имеется ряд распространённых протоколов SAN корпоративного класса, таких как iSCSI (SCSI поверх IP), FibreChannel, FCoE (Fibre Channel поверх Ethernet), FC-NVMe (NVMe поверх Fiber Channel) и тому подобные. Всякий протокол SAN представляет свои собственные преимущества и проблемы и, как правило, некие производители предлагают небольшой выбор из их собственного оборудования, а потому выбор производителя обычно ограничит ваши варианты SAN и выбранный вариант SAN будет ограничен выбором альтернатив вашего производителя. Понимание всех этих протоколов перемещает нас из мира вычислительных систем в мир сетевых сред. В качестве системного администратора вы редко будете в состоянии выбирать или даже оказывать влияние на варианты проектирования SAN, обычно она будет выбираться за вас командами хранения, сетевых технологий и/ или платформ. Если вы всё же будете оказывать такое влияние, вам потребуется серьёзное изучение данных технологий, их преимуществ и их применимости к вашей рабочей нагрузке, но это выходит за рамки данного тома.

Блочное хранилище никуда не исчезнет. Как бы мы не восхищались новыми технологиями хранения, такими как объектное хранилище, блочное хранилище продолжает оставаться основой для всех прочих типов хранилищ. Мы должны разбираться в блочных хранилищах как физически, так и логически, поскольку мы будем применять хи множеством способов в качестве строительных блоков своих систем хранения. Блочное хранилище является мощным и вездесущим. Оно представляет собой основную часть хранилища с которым мы взаимодействуем на этапах проектирования и, ожидается, что оно и останется в основе всего что мы делаем в ближайшие десятилетия.

При выборе между локальным и удалённым блочным хранилищем существует важное эмпирическое правило: Вы всегда желаете применять локальное хранилище до тех пор, пока у вас не возникнет потребность, которую не может удовлетворять локальное хранилище. Или же вы никогда не захотите пользоваться удалённым хранилищем, пока у вас не будет иного выбора.

Обычно мы обнаруживаем файловую систему сидящей поверх блочного хранилища. Файловые системы выступают основным (а под основным я подразумеваю, что они составляют около 99.999% или более вариантов применения) способом окончательного хранения данных в вычислительных системах. Файловые системы это то, что хранит файлы, какими мы их и знаем, в хранилище нашего компьютера.

Файловая система это формат организации данных, который располагается поверх блочного хранилища и предоставляет механизм для организации, идентификации, хранения и выборки данных с применением аналогии файла. Вы применяете файловые системы ежедневно и повсеместно. Они применяются даже когда вы не можете наблюдать их будь то ваш настольный компьютер, сотовый телефон или даже телефон VoIP или микроволновая печь! Файловые системы повсеместны!

 

Файловые системы в действительности это базы данных

Если вы хотите на мгновение слегка пофантазировать со мной и быть честным, вы читаете книгу о передовых методах системного администрирования, поэтому мы с вами знаем, что вы любите вдаваться в некоторые существенные подробности, поэтому мы можем посмотреть что такое на самом деле файловая система. По своей сути файловая система представляет собой базу данных NoSQL, а именно файловую базу данных (по сути, специализированную базу данных документов), которая применяет сырое блочное устройство в качестве механизма хранения и способна лишь хранить и извлекать файлы.

Существуют и иные специализированные базы данных, которые напрямую применяют блочные устройства (часто именуемые сырыми хранилищами когда мы имеем дело с жаргоном баз данных), но это редкость. Файловые системы это тип данных, который настолько распространён, что он встречается гораздо чаще чем все прочие типы баз данных вместе взятые, что никто никогда даже не говорит и не представляет себе о том, что они вообще являются базами данных. Но под своим капотом они действительно выступают базой данных во всех смыслах.

Для показа непосредственного сопоставления, стандартная база данных, причём вне зависимости от типа, обладает стандартизованным форматом хранения, форматом выборки, механизмом (движком) базы данных и, в некоторых случаях, некого уровня управления базой данных (который зачастую позволяет применять множество инженеров базы данных в рамках единого интерфейса системы), а также интерфейса запросов для доступа к данным. Будете ли вы сравнивать с сервером MongoDB или MS SQL, вы обнаружите что файловая система ведёт себя идентично. Выбранная файловая система на диске это формат хранения, формат выборки это файл, механизм базы данных это накопитель соответствующей файловой системы, система управления базами данных в Linux это Virtual File System (виртуальная файловая система, которую мы обсудим позднее), а язык запросов это список базовых команд POSIX, реализованных на C (с образцами абстракций на основе оболочки, которые мы можем применять для удобства). Сопоставьте это со стандартными базами данных и вы не сможете отличить их друг от друга! Очень крутой момент!

После развёртывания вычислительной системы, с точки зрения хранения, почти всё что мы с ней предпринимаем связано с работой её файловой системы. Как правило, мы пристально сосредоточены на блочном хранилище на этапах проектирования, в то время как с файловыми системами на этапах администрирования. Но несомненно, нам надлежит верно спланировать свои файловые системы перед развёртыванием системы в рабочей среде. Надлежащее планирование файловой системы на самом деле является чем- то, что интенсивно упускается из виду, поскольку большинство людей просто принимают параметры по умолчанию и вообще редко задумаются о проекте файловой системы.

Большинство операционных систем обладают встроенной поддержкой нескольких различных файловых систем. В большинстве случаев операционная система обладает одной очевидно стандартной и первичной файловой системой и несколькими специальными файловыми системами, которые предназначены для применения в нишевых аппаратных устройствах или для совместимости с прочими системами. Например, Apple macOS применяет APFS (Apple File System) для всех обычных функций, но может применять ISO 9660 при работе с оптическими дисками или FAT32 и exFAT используются для совместимости с устройствами хранения Windows (такими как карты памяти USB или внешние жёсткие накопители). В Windows всё аналогично, но с NTFS вместо APFS. В последнее время Windows добавила для специальных требований одну альтернативную файловую систему, ReFS, однако она не широко применяется и осознаётся.

Тем не менее, в Linux у нас имеются различные варианты первичной файловой системы и множество вариантов файловых систем. У нас нет возможности обсудит все их здесь, однако мы поговорим о наиболее значительных, поскольку очень важно понимание зачем они у нас имеются и когда когда их выбирать. К счастью, в промышленных системах нам на самом деле нужно рассматривать только несколько ключевых продуктов. Если вы находите файловые системы интересными, вы можете изучить множество вариантов файловых систем Linux и вы даже можете обнаружить именно ту, которую вы особенно пожелаете применять где-то!

Вот ключевые файловые системы Linux, с которыми нам необходимо иметь дело в повседневных целях: XFS, EXT4, ZFS, BtrFS. Почти всё чем мы будем заниматься будет связано с одной из этих четырёх. Существует множество менее популярных файловых систем, которые хорошо интегрированы и исключительно работают, например, JFS и ReiserFS, но они почти никогда не применяются в промышленном варианте. Существуют более старые форматы, например EXT2 и EXT3, которые были заменены более поздними обновлениями. Имеется большое число файловых систем, которые являются стандартными для прочих систем, и которые можно применять в Linux, например, NTFS из Windows или UFS из семейства BSD. Также существуют стандартные нишевые файловые системы, такие как ISO 9660 и FAT32, о которых мы упоминали ранее. Linux даёт вам варианты на каждом шагу и выбор файловой системы отличный пример насколько непомерным он может быть.

 

EXT: семейство файловых систем Linux

Почти все операционные системы обладают своей собственной файловой системой с особой изюминкой, которая применяется естественным образом по умолчанию и тесно ассоциируется с ней, и Linux не исключение ... шучу, Linux является исключением, что удивительно, принимая во внимание насколько Linux более устойчив в своих вариантах файловой системы, по сравнению с прочими операционными системами. У Illumos имеется ZFS, FreeBSD обладает UFS, Windows имеет NTFS, macOS имеет APFS, AIX имеет JFS, IRIX обладала XFS и так далее, и тому подобное. У Linux и в самом деле нет собственной файловой системы, но она имеется почти у всех прочих.

Большинство людей говорят о семействе файловых систем EXT как о собственной файловой системе Linux, и уж точно ничто иное не подходит под это описание. Когда Linux только разрабатывался, задолго до того как кто- либо фактически запустил её, на него была перенесена файловая система MINIX и она и стала файловой системой по умолчанию когда эта новая операционная система начала набирать обороты. Но, как это следует из её названия, файловая система MINIX была родной для MINIX и вообще предшествовала Linux.

Всего через год после первого представления Linux на основе файловой системы MINIX была создана файловая система EXT (или EXTended - расширенная - файловая система MINIX) и, как вы уже догадались она была расширена новыми функциональными особенностями, в основном, связанными с метками времени.

По мере того как Linux начал расти, вместе с ним росла и EXT, и всего через год после первого выпуска EXT была выпущена его преемница, EXT2, которая превратила эконишу файловой системы Linux из системы для хобби в серьёзную корпоративную систему. ECT2 почти исключительно рулил экосистемой Linux с момента появления в 1993 году до 2001 года, когда Linux претерпела небольшую революцию файловой системы. EXT2 была настолько большим скачком вперёд, что она была перенесена на саму MINIX, а в других операционных системах, таких как Windows и macOS появились её драйверы. Вероятно, ни одна файловая система не ассоциируется с Linux более символично, нежели EXT2.

К 2001 году многие операционные системы стремились к более современным технологиям файловых систем чтобы предоставить им конкурентное преимущество по сравнению с имевшимся рынком и Linux осуществила это, предоставив больше вариантов файловых систем и добавив функциональность журналирования в EXT2 для увеличения её версии до EXT3. Это придало нашему семейству EXT столь необходимую стабильность.

Ещё семь лет, и мы получили ещё одно серьёзное обновление почти родной файловой системы Linux с EXT4. Удивительно, но первичный разработчик EXT3 и EXT4 заявил, что хотя EXT4 и была большим шагом вперёд, но по сути это была временная мера добавления улучшений в то, что во многом относится к технологии 1980-х годов. Принципы проектирования файловых систем сильно продвинулись вперёд, в особенности в начале 2000-х годов, и семейство EXT, скорее всего, пребывает в конце своего пути, хотя у него ещё много полезной жизни на нём.

Я намерен слегка углубиться в подробности каждой из основных вариантов файловых систем, но чтобы было ясно, это лишь беглый взгляд. Подробности файловой системы могут быстро меняться и отличаться между версиями или реализациями, поэтому для и в самом деле конкретных подробностей, таких как максимальный размер файла, число файлов, размера файловой системы и прочего, пожалуйста, обращайтесь к Wikipedia или документации файловой системы. Вам не нужно будет запоминать эти подробности и вам редко будет нужно знать о них. В 1990-х ограничения файловой системы были настолько впечатляющими, что вы остро должны были осознавать их и обходить их на каждом шагу. В наши дни любая файловая система, которую мы собираемся применять, способна обрабатывать почти всё что мы ей подбрасываем, поэтому мы на самом деле хотим разобраться где сияют или дают сбои те или иные продукты и когда какие из них рассматривать на неком верхнем уровне.

Linux, как класс, не обладает файловой системой по умолчанию, как прочие операционные системы, но если вы попытаетесь заявить что сегодня этого звания заслуживает какая- нибудь файловая система, эта честь должна достаться EXT4. В наши дни большая часть развёртываемых на основе Linux операционных систем в качестве файловой системы по умолчанию выбирают EXT4, а никакую- нибудь иную. Но состояние дел начинает меняться, а потому маловероятно что EXT4 будет оставаться доминирующей ещё более пары лет.

EXT4 быстра и надёжна, достаточно гибка, хорошо известна и удовлетворяет потребностям практически любого развёртывания. Это мастер на все руки среди файловых систем Linux. Для типичного развёртывания она будет работать достаточно хорошо.

EXT4 это файловая система, которую мы называем чистой файловой системой, что означает что это всего лишь файловая система и она не делает ничего кроме этого. Это делает более простым её понимание и применение, но также и превращает её в более ограниченную.

Как и семейство EXT, XFS восходит к ранним 1990-х и происходит от конкурента Linux, в данном случае от системы UNIX IRIX SGI. Она почтенна и надёжна и была портирована в Linux в 2001 году, в том же году, когда была выпущена EXT3. На протяжении 20 лет EXT3/4 и XFS боролись за сердца и души администраторов Linux (и создателей дистрибутивов Linux при выборе их в качестве файловой системы по умолчанию).

XFS тоже чистая файловая система и очень часто применяется. XFS знаменита своими чрезвычайно высокими производительностью и надёжностью. XFS порой конкретно рекомендуется высоко производительными приложениями, такими как базы данных для поддержки их в рабочем состоянии при их пиковых нагрузках.

Вероятно, XFS является наиболее применимой файловой системой когда системный администратор намеренно выбирает файловую систему, а не просто берёт систему по умолчанию, скорее всего, её чаще всего рекомендуют производители приложений, и это мой личный выбор для большинства рабочих нагрузок, в которых потребности хранения не тривиальны.

С годами росла популярность EXT4 и XFS. Мои собственные наблюдения говорят о том, что с годами XFS выдвигается вперёд.

Одним из наиболее часто упоминаемых недостатков XFS по сравнению с EXT4 является то, что EXT4 может либо сжимать, либо расширять том после его развёртывания. XFS может увеличивать , но не способна уменьшать развёрнутый том. Тем не менее, для правильно развёрнутой промышленной системы почти неслыханно сжимать файловую систему, а потому обычно рассматривается как мелочь и не имеет отношения к принятию решений в отношении файловой системы (в особенности с появлением блочного хранилища с динамичным выделением ресурсов).

Выпущенная для Solaris в 2006 году, ZFS обычно рассматривается основной действительно современной архитектурой файловой системы. К тому времени, когда в 2001 году началась работа над ZFS, сама индустрия уже начала очень серьёзно относиться к проектированию файловых систем, причём регулярно вводилось множество новых концепций, но именно ZFS на самом деле вывела эти парадигмы проектирования на новый уровень и ZFS до сих пор остаётся существенным лидером во многих областях.

ZFS и в самом деле обладала на верхнем уровне тремя областями, в которых она попыталась полностью разрушить отрасль файловых систем. Первая это размер: ZFS была способна выполнять адресацию на несколько порядков большую по сравнению с предшествующими файловыми системами. Второе это надёжность: ZFS представила более надёжные механизмы защиты данных, чем прочие файловые системы, что позволило в значительной степени защититься от утраты данных. И третье, интеграция: ZFS стала первой настоящей не чистой файловой системой, в которой ZFS представляла собой файловую систему, систему RAID и диспетчер логических томов, встроенными в единый драйвер файловой системы. Позднее в этой главе мы рассмотрим RAID и LVM. Такая интеграция имела большое значение, поскольку она, как никогда раньше, позволяет самим слоям хранения взаимодействовать и выполнять координацию своих действий. Чистые файловые системы, такие как EXT4 и XFS способны применять и используют такие технологии, но через внешние компоненты вместо встроенных.

Хотя ZFS не нова и она применяется в промышленных системах не менее пятнадцати лет, но для Linux она совершенно новая. Потребовалось много лет прежде чем портация ZFS стала доступной в Linux, а затем прошло много лет, на протяжении которых проблемы с лицензированием не позволяли выпускать её в пригодном для применения формате в Linux. На сегодняшний день единственным крупным дистрибутивом, который официально поддерживает и упаковывает ZFS выступает Ubuntu, но доминирующее положение Ubuntu на рынке автоматически превращает ZFS в широкодоступную. На данный момент прошло менее двух лет с тех пор, как ZFS стало можно применять в качестве загрузочной корневой файловой системы в Ubuntu. Таким образом, ZFS является совершенно новой в промышленной среде Linux любым широко распространённым способом. Кажется, что её применение теперь быстро растёт, когда она стала доступной.

Вероятно, на момент написания этих строк, ZFS представляет собой наиболее современную, надёжную и масштабируемую файловую систему из доступных в Linux. Следует отметить, что чисто с точки зрения производительности на базе файловой системы такой ZFS, как известно, не блещут. Редко когда полезной считается настройка производительности на уровне самой файловой системы, но когда это современные файловые системы со всей их дополнительной надёжностью, они, как правило, не способны конкурировать со старыми и более базисными файловыми системами. Это следует подчеркнуть, так как часто предполагается, что более современные файловые системы также автоматически будут быстрее. Здесь это не тот случай. {Прим. пер.: подробнее в наших переводах Мастерство FreeBSD: ZFS Майкла В. Лукаса и Аллана Джуда, 2015 и ZFS для профессионалов Майкла В. Лукаса и Аллана Джуда, 2016.}

Произносимая как Butter-F-S, BtrFS это серьёзная попытка наших дней создать родную Linux файловую систему (предыдущая попытка с названием ReiserFS в начале 2000-х годов получила некую поддержку, но закончилась плохо по не связанным с техническими проблемам). BtrFS предназначена для имитации работы ZFS, но естественной для Linux и с совместимой лицензией.

BtrFS значительно отстаёт от ZFS, поскольку не реализованы ещё многие функциональные возможности, но работа над ними продолжается. BtrFS вполне жива и всё больше дистрибутивов Linux поддерживают её и даже выбирают в качестве файловой системы по умолчанию. BtrFS представляется наиболее вероятным долгосрочным будущим для Linux.

Как и ZFS, BtrFS это современная интенсивно интегрированная файловая система, которая начинает включать в себя функциональные возможности уровней стека хранения RAID и LVM . На сегодняшний день самое слабое место BtrFS это производительность.

Это подводит итог четырём текущим вариантам промышленной файловой системы, с которыми вы, скорее всего, столкнётесь или будете нести ответственность за выбор между ними. Помните, что вы можете смешивать и сочетать файловые системы в одной системе. В действительности очень часто используется в качестве загрузочной файловой системы для основных функций операционной системы применяется EXT4, в то время как затем полагаются на XFS для файловой системы высокопроизводительного хранилища базы данных или на BtrFS для файловой системы большого файлового сервера. Пользуйтесь ием, что имеет смысл для рабочей нагрузки на индивидуальном уровне файловой системы. Не думайте что вы обязаны прикрепляться к применению только одной файловой системы во всех системах, не говоря уж об одной системе!

Большинство реально технически сложных сторон файловых систем связаны с алгоритмами поиска и сохранения битов в блочных устройствах. Подробности таких алгоритмов выходят далеко за рамки не только данной книги, но и системмного администрирования в целом. Если вы интересуетесь файловыми системами, изучение того как именно хранятся, защищаются и извлекаются данные с диска может быть поистине увлекательным занятием. Для задач системного администрирования достаточно разбираться в файловых системах на верхнем уровне.

К сожалению, нет никакого способа предоставления настоящей передовой практики выбора файловой системы. Вряд ли у вас будут причины серьёзно рассматривать применение в промышленной среде какой бы то ни было не упомянутой тут редкой операционной системы, но все перечисленные здесь четыре обладают ценными вариантами применения и все их следует рассмотреть. Часто собственно выбор файловой системы не осуществляется изолированно, если только вы не работаете с очень специфичным продуктом, который требует или рекомендует для какой- либо функциональной возможности конкретную систему. Вместо этого, как правило, выбор файловой системы будет зависеть от многих прочих решений по хранению, включая RAID, LVM, потребности в физической поддержке, дисковых накопителей и тому подобного.

Все обсуждавшиеся нами до сих пор файловые системы, независимо от того насколько они современны, являются стандартными файловыми системами или файловыми системами без совместного применения. Они жизнеспособны только когда доступ гарантирован к осуществлению только из единственной операционной системы. Почти во всех случаях этого вполне достаточно.

Однако, если вы вспомните наше обсуждение SAN, мы упоминали, что имеются варианты применения при которых мы могли бы пожелать чтобы множество вычислительных систем были бы способны считывать и записывать в одной и той же области хранения в одно и то же время. Кластерные или файловые системы с разделяемым хранилищем это именно тот механизм, который позволяет нам такую работу.

Кластерные файловые системы работают в точности как обычные файловые системы, однако с добавлением функциональных возможностей, посредством коих они будут записывать блокировки и совместно использовать сведения в своей файловой системе с тем, чтобы множество вычислительных систем были способны координировать её применение между подключёнными узлами. В некой стандартной файловой системе имеется лишь один компьютер, выполняющий доступ к своей файловой системе за раз, а потому знает какой файл открыт, когда приходится выполнять обновление, когда запись кэширована и тому подобное, а потому обрабатывается в оперативной памяти. Когда два или более компьютеров пытаются совместно использовать данные из традиционной файловой системы, они не способны разделять эти данные в оперативной памяти и поэтому неизбежно будут разрушать данные, поскольку они перекрывают изменения друг друга, отказывать в определении обновлённых файлов и выполнять всякие гадости из устаревших кэшей записи!

Поскольку единственным общим компонентом таких систем выступает сама файловая система, все взаимодействия между имеющими доступ к этой файловой системе обязаны происходить в самой этой файловой системе! Буквально не существует иного пути без перехода к механизму, который больше не выступает совместным хранилищем, а выступает совместным вычислителем, что намного сложнее и дороже.

Для описания самым простым способом как работают кластерные файловые системы, мы можем себе представить себе что всякий компьютер знает что определённая часть блочного устройства (дисков) выделена в чрезвычайно жёстком формате и размере под область, в которой все узлы считывают и записывают своё текущее состояние взаимодействия с конкретной файловой системой. Когда узлу A необходимо открыть файл X, он поместит замечание о том, что он удерживает такой файл открытым. Если узел B удалит файл, он поместит замечание о том, что он собирается удалить и обновить его после удаления файла. Узел C может сообщить какое именно действие происходит, просто прочитав этот небольшой фрагмент файловой системы. Все подключённые узлы знают, что нельзя выполнять кэширование данных из этой области, что необходимо сообщать о любых действиях, которые они планируют предпринимать и регистрировать всё, что они выполнили. Если какой- то из узлов ведёт себя неправильно, повреждается вся система, а данные утрачиваются. {Прим. пер.: подробнее о теории распределённых систем в нашем переводе Внутреннее устройство баз данных Алекса Петрова, O`Reiily, 2019}

Естественно, как вы можете заметить, это, как минимум, создаёт большие накладные расходы на производительность. И такая система требует абсолютного доверия между всеми подключаемыми узлами, поскольку управление доступом и целостностью данных оставлено на усмотрение отдельных узлов. Нет и не может быть никакого механизма, заставляющего все узлы вести себя корректно. Узлы обязаны делать это добровольно. Это означает, что любая ошибка в коде, любой сбой памяти, любой администратор с правами root, любое вредоносное программное обеспечение, получившее доступ к отдельному узлу, а также всё прочее, способны обойти абсолютно любые элементы управления и считывать, изменять, уничтожать, шифровать и так далее, причём в любой степени, в которой пожелает, а при этом не существуют никакие виды безопасности и средств контроля, которые, как мы обычно предполагаем, защищают нас. Совместно используемое хранилище чрезвычайно простое, но мы настолько привыкли к абстракциям хранения, что становится сложно думать о том, что любая система хранения может быть настолько простой.

Как и в случае с обычными файловыми системами, Linux обладает множеством кластерных файловых систем, которые мы можем наблюдать в применении. Наиболее распространённой является GFS2, за которой следует OCFS2.

Как и в целом с SAN, то же самое правило применимо и кластерным файловым системам: вам не следует желать их применения, пока это вам не требуется.

Сетевые файловые системы всегда немного сложно описывать, но когда вы обнаружите это явление и узнаете о нём, они принесут вам пользу. В отличие от обычных файловых систем, которые располагаются поверх блочного устройства и обеспечивают доступ к хранилищу в виде файлов, сетевые файловые системы получают некую файловую систему и расширяют её на сетевую среду. Это может звучать подобно SAN, но это совсем иное. SAN совместно применяет в сетевой среде набор блочных устройств. Сетевые файловые системы в сетевой среде совместно используют файловые системы.

Сетевые файловые системы достаточно распространены и, скорее всего, вы наблюдаете их ежедневно, однако часто мы не задумываемся о том, чем они являются на самом деле. Зачастую мы просто именуем сетевые файловые системы как совместные ресурсы или подключаемые диски, а стандартными протоколами применения выступают NFS и SMB (порой называемым CIFS, что не совсем точно). Реализующие сетевые файловые системы серверы называются файловыми серверами, а когда вы превращаете файловый сервер в устройство, он носит название NAS (или Network Attached Storage, подключаемого через сеть хранилища). По этой причине о сетевых файловых системах также часто говорят как о протоколах NAS, точно так же как блочные сетевые протоколы считаются протоколами SAN.

В отличие от протоколов совместного применения блоков, сетевые файловые системы являются интеллектуальными, поскольку разделяющая это хранилище машина обладает локальной файловой системой, которую он понимает, а также понимает сведения о задействованных файлах, а потому такие понятия, как блокировка файлов, кэширование, обновление файлов и тому подобное, могут обрабатываться через одного привратника, который способен обеспечивать безопасность и целостность, а также нет необходимости доверия узлам доступа. Ключевое отличие состоит в том, что SAN это просто хранилище, вслепую подключаемое к сетевой среде, оно может быть настолько же простым, как сетевой адаптер, прикручиваемый к жёсткому диску (и зачастую это так и есть на самом деле). С другой стороны, реализующее сетевую файловую систему устройство является сервером и требует для своей работы ЦПУ, оперативной памяти и некой операционной системы. Разделяемое блочное устройство почти исключительно применяется в ограниченных развёртываниях с тщательно контролируемыми серверами. Сетевые файловые системы можно применять практически везде, где можно применять SAN, но они также используются для совместного применения хранилища непосредственно с устройствами конечных пользователей, поскольку их надёжная безопасность, простота применения и отсутствие доверия к оконечной точке превращают их в очень полезные там, где SAN невозможно развернуть.

Сетевые файловые системы запускаются как некий дополнительный уровень с включением сетевой среды поверх традиционных файловых систем и не замещают файловые системы на диске, которые уже имеются. Говоря на языке интерфейса, мы бы описали сетевые файловые системы как потребляющие интерфейс файловой системы, а также и представляющие интерфейс файловой системы. В целом это файловая система на входе, файловая система на выходе.

Как и традиционные файловые системы, Linux в действительности предлагает большой диапазон вариантов сетевых файловых систем, причём многие из них являются по своей природе историческими или чрезвычайно нишевыми. Распространённым примером выступает предлагаемый Linux Apple Filing Protcol или AFP (также именовавшийся как AppleTalk), однако не применяющийся в наши дни в промышленных операционных системах. В любом случае, на сегодня лишь NFS и SMB в действительности наблюдаются в реальной практике.

 

NFS

Собственно первоначальная сетевая файловая система широко применяется и буквально выступила источником названия, NFS, восходит к 1984 году! NFS не может быть родной для Linux, поскольку она старше Linux на семь лет, однако NFS была сетевой файловой системой по умолчанию во всех операционных системах на основе UNIX, или вдохновлённых ею с момента её создания и являет собой достаточно важный стандарт таковой. По причине того что Linux в наши дни настолько популярна, большинство людей полагают NFS протоколом Linux.

NFS доступна практически во всех системах. Любая система UNIX, причём даже macOS, предлагает NFS, и даже Windows Server! NFS является открытым стандартом и при этом практически универсальным. NFS поддерживает популярность за счёт простоты применения, надёжности в сетевой среде и в целом хорошей работы. NFS по- прежнему активно применяется в серверах, когда требуется непосредственный файловый обмен между системами, в особенности в системах резервного копирования.

 

SMB

Протокол Server Message Block (SMB) предшествовал NFS и первоначально был доступен в 1983 году. Это действительно очень старые протоколы. SMB не нашёл широкого распространения до тех пор, пока Microsoft начала продвигать его примерно в 1990 году, а с появлением платформы Windows NT в 1990-х годах он превратился в достаточно популярный.

SMB и в самом деле выиграл от интенсивного применения Microsoft подключаемых дисков между своими серверами и рабочими станциями, что превратило SMB в очень заметный для специалистов, причём как обычных, так и технических.

В Linux поддержка протокола SMB предоставляется пакетом Samba (шутка в отношении букв SMB). Linux хорошо поддерживает SMB, однако его применение намного сложнее нежели работа с NFS.

Выбор между NFS и SMB для необходимого в Linux обмена файлами обычно спускается к варианту использования. При преобладающей работе с системами UNIX, обычно больше смысла применять NFS. При преобладающей работе с системами Windows обычно практичнее выбирать SMB. Они оба мощные и надёжные и способны обслуживать широкий диапазон потребностей.

Принятие решения может становиться чрезвычайно трудным в тех случаях, когда мы способны удовлетворять одну и ту же потребность совершенно разными способами. Например, когда вам необходимо предоставлять серверы совместного хранения для виртуализации, у вас может иметься вариант сетевой файловой системы, такой как NFS, или же кластерной файловной системы в SAN, например, GFS2. Такие два подхода непросто сопоставлять, поскольку каждая из сторон этих двух систем, скорее всего, будет иной, включая производителя и аппаратные средства, а потому сравнения должны выполняться на уровне полного стека, а не на уровне сетевых технологий.

Теперь, когда мы изучили технологии файловых систем и увидели широкую сферу вариантов файловых систем реального мира для систем Linux, а также рассмотрели как файловые системы могут быть локальными или удалёнными, с выделенным доступом или кластерными, чтобы допускать множество переносчиков доступа. В то же самое время у нас имеется хорошее понимание как подход к решению вовлечен в выбор и настройку файловой системы. Мы знаем когда выбирать различные технологии файловых систем, а также на что обращать внимание в новых или альтернативных системах, которые мы, возможно, тут и не рассматривали. Файловые системы не должны пугать или сбивать с толку, но они могут быть ценными инструментами в нашем наборе ухищрений, которыми мы можем пользоваться для тонкой настройки своих систем с точки зрения безопасности, масштабируемости, доступа или производительности. Далее мы рассмотрим одну из наименее изученных областей хранения - логический том.

Я ненавижу применять такие термина, как новые технологии, который применялся в конце 1980-х годов, однако по сравнению с большинством понятий в хранении компьютеров, диспетчер логических томаов (logical volume management, LVM) достаточно новый и далеко не столь известный по сравнению с прочими стандартными технологиями хранения для большинства системных администраторов. LVM относились к исключительно высокопроизводительным серверным системам до того, как Linux представила широко доступный продукт в 1998 году, а Microsoft последовала её примеру в 2000 году. В наши дни LVM повсеместно распространены и доступны в большинстве операционных систем, причём зачастую и по умолчанию.

LVM это основная применяемая в наши дни технология виртуализации хранилища. LVM позволяет нам получать произвольное число блочных устройств (имеется в виду одно или несколько, обычно именуемых физическими томами) и сочетает, разделяет или иным образом изменяет их и представляет их системе как произвольное число блочных устройств (обычно называемых логическими томами). Это может показаться сложным, но в действительности это не так. Практический пример может показаться достаточно простым.

Например, у нас имеется вычислительная система, к которой подключены три жёстких диска. Они могут быть все одинаковыми, а могут быть разными. Фактически, один из них может быть традиционным шпиндельным жёстким диском, один современным SSD, а третий внешним накопителем USB (либо RAID массивом, SAN, или как там вы его называете). Мы можем все три добавить в своё LVM как физические тома. LVM позволит нам рассматривать это как единый пул хранения и превращать его в любую желаемую нам конфигурацию. Мы могли бы превратить всё это в один логический том, чтобы просто получить из этих трёх один логический том. Или же мы бы могли создать дюжину логических томов и применяли бы каждый из них для разных целей. Мы можем иметь столько физических томов, сколько пожелаем и создавать столько логических томов, сколько захотим. Логические тома могут быть любого размера (в некоторых случаях даже больше значения общего физического размера!) Мы не ограничены традиционными размерами дисков. При работе с логическими томами мы часто находим полезным создавать больше томов меньшего размера, чтобы иметь больше возможностей для управления и изоляции.

При помощи LVM мы можем себе представлять систему как потребляющую блочное устройство и представляющее блочное устройство. Поскольку LVM применяют и предоставляют блочные устройства (иначе - внешнее представление дисков), они могут составляться в стек, то есть, если вы хотите, вы можете обладать блочным устройством, в котором находится LVM, который создаёт логический том, который применяется другим LVM, который создаёт другой логический том, применяемый иным LVM и так далее. Это ни разу не практично, но помогает визуализировать как LVM располагается в стеке хранилища. Он всегда где- то посередине, но кроме того что он пребывает в среднем положении, он чрезвычайно гибкое.

Чтобы являться LVM, LVM требуется не только предоставлять такую базовую функциональность блоков на входе, блоков на выходе, но также и прочие функциональные возможности, которые обычно добавляются в LVM чтобы и в самом деле превращать их в невероятно полезные. Некоторые из наиболее стандартных свойств, которые мы ожидаем обнаружить в LVM, включают изменение размера логических томов в реальном режиме времени, горячее подключение физических устройств, функциональность моментальных снимков, варианты кэширования, а также динамичное предоставление.

В Linux, как и с большинством прочих вещей, у нас имеется не одно, а множество диспетчеров логических томов! Это становится всё более распространённым, поскольку в последние годы это превратилось в тенденцию создавать интегрированные файловые системы со своими собственными LVM. В наши дни в промышленном Linux у нас имеются LVM2, ZFS и BtrFS. Естественно, вы признаёте, что две последние являются файловыми системами, о которых мы упоминали ранее. Когда большинство людей говорят о диспетчере логических томов в Linux, они имеют в виду LVM2, обычно просто называемом LVM. но интегрированные диспетчеры логических томов ZFS и BtrFS также превращаются во всё более популярные подходы.

По причине своей природы составления в стек, некий LVM, который потребляет и производит блочные устройства, мы, если пожелаем, имеем возможность применять LVM2 в сочетании с ZFS или BtrFS и можем либо отключить интегрированные в них уровни LVM как ненужные, либо можем пользоваться ими, если у них имеются функциональные возможности, которые мы бы захотели применять для получения преимуществ! Рассказывайте мне о гибкости.

Если вы вспомните работу в ИТ в 1990-е, в разговорах мы непрерывно пользовались разбиением дисков на разделы. Это была постоянная тема. Как вы настроили всои разделы, сколько вы их сделали, базовые и расширенные разделы, какое программное обеспечение для разбиения на разделы применять и так далее, и тому подобное. Конечно, разделы всё ещё существуют, просто они нам уже очень давно не нужны (со времён Windows 2000 Linux или 2.4, например).

Разделы это очень жёсткая система на диске для нарезки физического диска на отдельные области, каждая из которых способна представляться системе как индивидуальное блочное устройство (или накопитель). Таким образом, разделы подобны самому базовому LVM, но без необходимой гибкости. Разделы ограничены существованием как часть отдельного блочного устройства и для отметки того какие области этого блочного устройства относятся к каким разделом и хранятся в простой таблице разделов в самом начале такого устройства.

Разделы были предшественниками логических томов и некоторые люди всё ещё применяют их (но только лишь по той причине, что они не знакомы с логическими томами). Разделы не являются гибкими и лишены важных особенностей, таких как динамичное предоставление и моментальные снимки, которые могут предоставлять логические тома и, хотя изменение размера раздела технически возможно, оно не гибкое, жёсткое и чрезвычайно рискованное.

Всё что предлагали разделы, также предоставляется и LVM, плюс много чего ещё, не отказываясь ни от чего. Потребность в разбиении (создании нескольких файловых систем из блочного устройства) с годами значительно уменьшилась. В конце 1990-х это было стандартным и почти необходимым, чтобы даже самый простой сервер, а часто и настольный компьютер, имели веские основания быть разделёнными на разные файловые системы. В наши дни гораздо чаще объединяют множество блочных устройств в единую файловую систему. В основном, это связано с тем, что производительность и надёжность файловой системы полностью изменились, а движущие факторы для разбиения на разделы ослабли. И в наши дни имеются веские причины разделения файловых систем. Нам прсото приходится делать это гораздо реже.

В наши дни многие механизмы, такие как утилиты резервного копирования, пользуются всей мощностью уровня своего LVM для осуществления таких задач как заморозка значения состояния своего блочного устройства с тем, чтобы можно было бы взять полную резервную копию. Поскольку LVM работает ниже окончательного уровня файловой системы, у него имеются определённые возможности, которые отсутствуют на прочих уровнях. LVM это уровень хранения, на котором мы получаем наименее критически важные функциональные возможности, но как правило, именно на нём и происходит всё волшебство. LVM дают нам возможность изменять схемы хранения после первоначального развёртывания и взаимодействовать с такими системами хранения на блочном уровне. LVM это центральный технологический компонент, обеспечивающий ощущение современной операционной системы двадцать первого века.

Естественно, всякий новый технологический уровень будет обладать собственными оговорками. LVM добавляет ещё один уровень сложности и дополнительные элементы для понимания системным администратором. Научиться управлять LVM вряд ли гигантской сложности предприятие, но это совсем немногим больше для изучения, чем при его отсутствии. LVM также привносят небольшой объём накладных расходов производительности, поскольку они выполняют преобразование между физическими и логическими устройствами. Как правило, это и в самом деле совсем небольшие накладные расходы, но всё же это накладные расходы.

В целом, преимущества LVM значительно перевешивают затраты, и всё больше и больше систем начинают просто развёртывать уровень LVM, не спрашивая пользователя хочет он того или нет, потому как возрастающие функциональные возможности, которые ожидают получать клиенты от операционной системы, зависят от уровня LVM, а возможность развёртывания систем без него часто оставляет клиентов в затруднительном положении без понимания почему их системы не оправдывают ожиданий, а часто ещё и так, что они не осознают этого в течении месяцев или лет после первоначального развёртывания.

Как и прочие виды виртуализации, виртуализация хранилища и LVM наиболее важны для защиты от неведомого. Когда мы знаем всё относительно того как система будет применяться на протяжении своего жизненного промежутка, такие моменты, как изменение размера, резервное копирование, совместная работа и тому подобное будут иметь небольшую ценность, но это совсем не то что происходит в реальном мире.

Общепризнаны такие рекомендации, когда речь заходит об LVM: если вы не можете точно предоставить веские технические причины почему накладные расходы LVM будут значительными и что такое воздействие перевешивает обеспечиваемую LVM защиту, всегда развёртывайте LVM.

Диспетчер логических томов предоставляет критически важные строительные блоки для надёжных решений хранения и, во многих случаях, являются тем, что отделяет современные хранилища от классических вычислительных систем. Понимание того, как логические тома абстрагируются от концепций хранения и позволяют нам манипулировать хранилищем и строить его чтобы оно действовало именно так как мы желаем, даёт нам множество вариантов и приводит нас к дополнительным понятиям, таким как RAID и RAIN, которые мы и обсудим далее и которые применяют LVM для возможностей построения защиты данных, расширения и повышения производительности.

Мы рассмотрели очень большое число способов взаимодействия с нашими хранилищами. Однако, вероятно самый захватывающий начинается когда мы имеем дело с RAID (Redundant Array of Inexpensive Disks, Массивом экономичных дисков с избыточностью) и с его потомственным расширением RAIN (Redundant Array of Independent Node, Массивом независимых узлов с избыточностью). Прежде чем мы двинемся далее, следует отметить, что RAID это гигантская тема, которая потребовала бы целой книги сама по себе чтобы по- настоящему раскрыть её осмысленным образом. Понимание того как работает RAID, а также все расчёты, необходимые для того чтобы разбираться со всеми нюансами его производительности и рисков это главный предмет сам по себе. Моя цель здесь состоит во введении в само это понятие, пояснении того как это укладывается в проектирование и выставить их общепринятые рекомендации, а также подготовить вас к дальнейшим исследованиям.

RAID и RAIN это механизмы для того, чтобы взять множество устройств хранения (блочных устройств) и воспользоваться естественным умножением устройств (зачастую ошибочно называемое избыточностью) для предоставления некого сочетания улучшения производительности, надёжности или масштабируемости по сравнению с теми возможностями, которыми обладает лишь одно устройство. Как и LVM, RAID и RAIN это технологии (промежуточного стека), которые употребляют интерфейсы блочных устройств и предоставляют интерфейсы блочного устройства, а следовательно, способны составляться в стек поверх LVM, под LVM, поверх иного RAID, либо поверх смеси аппаратных устройств и тому подобного. Это очень гибко.

Фактически, RAID и RAIN в действительности это особый вид LVM! Никто и никогда не обсуждает эти технологии подобным образом, и на вас кинут ряд странных взглядов на рождественской вечеринке в компании, если вы начнёте обсуждать RAID как специализированный LVM, но на самом деле это именно так. RAID и RAIN это предельное подмножество функциональных возможностей LVM с очень узкой направленностью. Как ни странно, нет ничего необычного в том, что LVM общего назначения обладают встроенными функциональными возможностями RAID, а основная тенденция интегрированных файловых систем состоит в том, чтобы уровни LVM и RAID были интегрированы в саму файловую систему.

RAID это стандарт для Redundant Array of Inexpensive Disks (Массива экономичных дисков с избыточностью) и он первоначально был представлен как некий набор технологий, которые работали на собственно блочном уровне для превращения множества устройств в одно. Подобные RAID технологии уходят корнями далеко в 1960-е, а сам термин и современные определения восходят к нам из 1988, что означает, что RAID, на самом деле, предшествовал наиболее общим целям LVM.

RAID по- существу получает некий массив блочных устройств и выстраивает их в жёсткую конфигурацию друг с другом под один из множества различных режимов хранения данных, носящих название уровней. Всякий уровень RAID действует отличным образом и применяет различные механизмы для слияния всех лежащих в основе дисков в единый виртуальный диск. Заставляя множество устройств выступать так, как если бы они представляли единое устройство, мы способны расширять различные стороны своего хранилища, но выигрыш в одной из областей обычно приводит к потерям в другой, а потому важно понимать как работает RAID.

RAID это область, в которой очень важно чтобы его системный администратор обладал глубоким пониманием внутренней работы подсистемы хранения. И что удивительно, в этой области очень немногие системные администраторы на самом деле знают как работает их система.

Хотя RAID определяется как некая последовательность уровней, не дайте себя обмануть этим. Такие уровни это всего лишь разные типы хранения, которые используют базовые основы RAID. В действительности уровни RAID не строятся друг на друге, и более верхний номер вовсе не представляет какой либо вышестоящий его по своей сути продукт.

Поскольку RAID это фактически некая разновидность LVM, он может располагаться в любом месте всего стека хранения и в свободном распространении может обнаруживаться почти где угодно. Некоторые очень популярные уровни RAID в действительности представляют собой составляемый в стек RAID, применяющий такой врождённый артефакт своей конструкции, в особенности RAID 10.

К тому же RAID поставляется как в аппаратном варианте, так и программным образом. Аппаратный RAID во многом схож с графической картой, которая подключается непосредственно к монитору и берёт на себя работу основных вычислительных систем и общается непосредственно с оборудованием. Аппаратная карта RAID осуществляет именно это, снижая нагрузку на основную вычислительную систему, напрямую взаимодействуя с аппаратными устройствами хранения и потенциально предлагая особые функциональные возможности (например, кэш) в общем оборудовании. Вместо этого, программно определяемый RAID применяет гораздо более мощные ЦПУ и оперативную память системы и обладает более гибкими настройками. Оба подхода вполне жизнеспособны.

Всякий уровень RAID обладает уникальным набором свойств и имеет смысл применять его в разных ситуациях. RAID это сложная тема, заслуживающая отдельного тома для надлежащей подготовки. RAID не является тем вопросом, который мы можем рассматривать очень бегло, что в прошлом представляло опасность для хранения. Параметры риска RAID зачастую сводятся к бессмысленным заявлениям, таким как численное указание сколько дисков способен восстанавливать RAID массив с уровнем X? Это вовсе ничего не значит, и задумано в качестве способа упрощения чего- то очень сложного, что можно запомнить просто или занести в карту. RAID так не работает. Каждый уровень RAID обладает сложной историей, связанной с производительностью, надёжностью, стоимостью, масштабируемостью, реализациями на практике и тому подобным.

Со временем, по мере того как системы укрупнялись и превращались в более сложные, имеющиеся ограничения в подходе RAID начинали превращаться в очевидные. RAID прост и лёгок в реализации. Однако RAID не гибок и имеется ряд ключевых функциональных возможностей, таких как простое изменение размера, автоматическая повторная балансировка и гибкий размер узла, который недостаточен для его обработки. Требовалось новое семейство технологий.

RAIN избегает подхода законченного блочного устройства к массивам, на котором основывался RAID и вместо этого разбивает хранилище на фрагменты меньшего размера, часто на блоки, и обрабатывает на этом уровне репликацию. Для действенного осуществления этого RAIN обязан понимать не только концепцию этих блоков, но и сами блочные устройства (или диски), на которых они находятся, а также те узлы, где они пребывают. Такая осведомлённость об узлах даёт и прозвище RAIN: Redundant Array of Independent Nodes (Массива независимых узлов с избыточностью).

Как ни странно, на самом деле в RAIN не сами узлы обязательно избыточны, а фактически блоки, и вы в действительности можете реализовать RAIN в одном физическом устройстве, чтобы непосредственно конкурировать с традиционным RAID в его простейшем виде, но это редко применяется.

Поскольку RAIN обрабатывает репликации блочного уровня, он способен обладать массой преимуществ над RAID. Например, он способен пользоваться устройствами разного размера достаточно текучим образом. Диски разного размера можно вставлять волей- неволей в серверы и связывать их воедино с великолепной эффективностью.

В случае с RAID, когда некое устройство отказывает, нам необходимо сменное устройство, способное занять своё место в нашем массиве. Это зачастую проблематично, в особенности со старыми массивами. RAIN способен избежать подобной проблемы, допуская любому сочетанию доступной ёмкости в массиве поглощать утраченную ёмкость отказавшего жёсткого диска.

RAIN поставляется в таком разнообразии реализаций, что каждая из них по существу уникальна и мы на самом деле не имеем возможности обсуждать её каким- либо стандартным образом. В наши дни большинство решений являются частными и, хотя было создано несколько хорошо известных открытых продуктов, которые стали стандартными компонентами экосистемы Linux, как правило, они являются внешними по отношению к дистрибутивам, но ведут себя в точности также как и проприетарные продукты в отношении того, как нам надлежит к ним подходить.

В будущем мы можем обнаружить значительную консолидацию или, по крайней мере, стандартизацию на рынке RAIN, поскольку такие технологии станут более доступными и понятными. До тех пор можно подходить к RAIN с пониманием того как может работать репликация блоков, и знать, что всякая реализация может создавать разные варианты конструкции. RAIN может быть встроенным в ядро или может существовать как приложение, работающее выше в общем стеке, в некоторых случаях он способен даже работать в некой виртуальной машине, виртуализируемой поверх гипервизора! Как будет реагировать RAIN на утрату диска, на балансировку нагрузки, привязку к местоположению, повторной балансировке после утраты, восстановлению после ремонта и т.п., не определяется ни каким стандартом. Для применения RAIN вам надлежит тщательно изучать любое рассматриваемое вами решение и критически продумывать то, как его артефакты повлияют на ваши рабочие нагрузки по ходу времени.

Почти наверняка RAIN станет будущим системных хранилищ. По мере того, как всё больше и больше мы продвигаемся к кластерам, гиперконвергенции, облачным и подобным облачным проектам, RAIN кажется всё более и более натуральным. По мере увеличения понимания принятие RAIN будет лишь увеличиваться. Просто это требует времени, хотя сама технология и не нова.

Почти всякая промышленная система, которую мы будем проектировать или поддерживать когда- либо, будет пользоваться тем или иным видом RAID или RAIN, причём локально или удалённо. К настоящему времени мы готовы подумать о том, как принятие решения о том, какой уровень или конфигурация RAID, либо какая именно реализация RAIN будут выбраны, окажут влияние на наши системы. Одна из самых ценных областей знаний верхнего уровня для системных администраторов всех направлений это затраты времени на глубокое понимание факторов хранения в таких взаимодействующих инфраструктурах агрегации. В своём следующем разделе мы будем опираться на эти технологии чтобы пронаблюдать как локальное хранилище можно сделать избыточным при помощи внешних систем или узлов.

Возможно, наиболее важным и наименее понятным типом хранилища является реплицируемое локальное хранилище (RLS, replicated local storage). RLS это не сложное понятие, оно достаточно простое. Однако имеется множество мифов вокруг прочих понятий, например SAN, и это омрачает функциональность RLS. К примеру, многие люди стали применять термин совместного хранилища в качестве посредника для внешнего хранилища или, возможно, для SAN. Однако внешнее хранилище не означает что оно выступает совместным или применяться в качестве такого, а локальное хранилище не означает что оно не является разделяемым или может использоваться совместно.

Собственно термин реплицируемого локального хранилища обозначает две или более вычислительных системы, которые обладают локальным хранилищем, которое реплицируется между ними. С точки зрения каждой вычислительной системы такое локальное хранилище подключается локально, в точности как обычное. Однако имеется некий процесс, который реплицирует необходимые данные из одной системы в другую с тем, чтобы выполненные в одной системе изменения появлялись в другой.

Достигать реплицированного локального хранилища можно множеством способов. Самый простой и наиболее ранний состоял в применении Сетевого RAID, то есть просто применения RAID технологии поверх сетевой среды. Зеркалируемый RAID (также именуемый как RAID 1) это самая простая технология для этого и служит отличным примером.

Существует два сценария обработки этого, один состоит в паре горячий/ холодный, в которой один узел является горячим и имеет доступ на запись в своё хранилище, а другой узел (узлы) способен считывать с него и, по всей видимости, становится доступным для горячей записи узлом, если выходит из строя исходный горячий узел или отказывает управление им. Данная модель проста и похожа на многие традиционные модели для общего хранилища в SAN. Такой подход позволяет применять обычные (без кластеризации) файловые системы, например, XFS или ZFS.

Другим подходом выступает система активный/ активный, в которой все реплицирующие своё хранилище узлы способны считывать и записывать в любое время. Это требует такой же поддержки кластерной файловой системы, которая понадобилась бы для любого совместного блочного хранилища. Точно так же как и в случае с SAN, используемом в одно и то же время двумя узлами, таким узлам в кластере RLS потребуется взаимодействовать сохраняя данные своих действий в особой области своей кластерной файловой системы.

Реплицируемые локальные хранилища способны сулить нам многие из преимуществ, обычно связываемых с SAN или прочими внешними хранилищами, а именно, возможность для множества узлов немедленно выполнять доступ. И при этом также обладать всеми преимуществами локальности, включая улучшенную производительность и эластичность поскольку имеется меньше зависимостей. Естественно, необходимый обмен репликациями обладает своими собственными накладными расходами, и они также подлежат учёту. Существует множество способов репликаций, которые могут быть настроены, причём некоторые обладают очень небольшими накладными расходами, а некоторые значительными.

Принято считать, что реплицируемое локальное хранилище является чем- то новым, новаторским или чем- то необычным. Ничто не может быть дальше этого от реальности. На самом деле редко кто осознаёт, что для систем хранения с высокой надёжностью всегда применяются RLS. Независимо от того, используется ли оно локально (то есть непосредственно подключено к вычислительным системам) или удалённо (а это означает, что удалённое хранилище применяет RLS для повышения надёжности), RLS лежит в основе практически любого уровня хранения с высокой доступностью.

RLS поставляется во многих качествах,в первую очередь это Сетевой RAID и RAIN. Мы могли бы называть его Сетевым RAID при применении в подобном случае, но мы этого не делаем. В отличие от RAID, который почти всегда является исключительно локальным, RAIN почти всегда применяется в случае с RLS, а потому почти подразумевается его сетевая природа или, по крайней мере, его сетевой вариант.

RLS применяется в Linux во многих видах, поэтому мы не можем говорить обо всех имеющихся вариантах. Нам придётся сосредоточиться на нескольких наиболее распространённых. RLS это область со множеством имеющегося открытого исходного кода, а также коммерческих и частных решений с широким спектром производительности, надёжности и функциональных возможностей; причём зачастую они реализуются по- разному. RLS может добавлять новый уровень сложности к любой ситуации с хранилищем, так как вы обязаны учитывать его взаимодействие с локальным хранилищем, взаимодействие с репликацией, любое потенциальное взаимодействие между узлами и удалённым хранилищем (локальным для иного узла), а также то, как сами алгоритмы и протоколы взаимодействуют друг с другом.

Самой первой и самой простой технологией реплицируемого локального хранилища (RLS) в Linux является DRBD или Distributed Replicated Storage System (Распределённой реплицируемой системой хранения), которая является просто уровнем Сетевого RAID, опирающегося непосредственно на само ядро Linux. Wikipedia постулирует DRBD не как Сетевой RAID, но затем описывает её в точности как Сетевой RAID. Будет она таковой или нет, это может быть не более чем семантика, на практике она неотличима от Сетевого RAID в применении, причём как на практике, так и по определению, и под капотом. Как и все RAID, DRBD употребляет блочные устройства и появляется как блочное устройство, допуская составление её в стек где угодно посреди всего стека хранения в точности как обычные RAID и LVM.

DRBD строится как механизм RAID 1 (зеркалируемый RAID), а потому допускает два и более узлов, причём каждый узел получает копию своих данных.

DRBD гибкая и надёжная, а по причине своей простоты она намного проще к ясному пониманию того как она работает и вкладывается в общую инфраструктуру хранения большинством системных администраторов. Однако по причине того что DRBD ограничена полной репликацией устройства через зеркалирование в качестве RAID 1, её возможность масштабирования достаточно ограничена. Сама по себе, DRBD в большей степени сосредоточена на классическом кластере из двух узлов или очень нишевых вариантах применения с большим числом вычислительных узлов, которым требуется совместно применять небольшое количество идентичных данных.

 

Делаем DRBD гибким

По причине того, что по- существу DRBD это всего лишь программный инструментарий RAID, а также потому что вы обладаете полным управлением ею, и кроме того, из-за того что RAID действует как некий LVM с полной гибкостью располагаться где угодно в неком стеке, вы можете взять DRBD и повернуть её в нечто намного более масштабируемое чем она представляется вначале. Но на данный момент весь этот процесс выполняется вручную, хотя в теории вы можете написать сценарий этого или создать инструмент для автоматизации данного вида процесса иным способом.

Один из мощных методов, к коем мы можем прибегнуть, состоит в концепции разнесения нашего RAID 1 при помощи дополнительных логических блочных устройств для имитации RAID 1E, который, по существу, работает как RAID 1, но является масштабируемым. Данная технология работает, беря физическое пространство хранения в отдельном узле и логически разбивая его на две (или более) секции при помощи технологии LVM. При стандартной настройке Сетевого RAID всё пространство хранения из узла 1 зеркально отражается на всё пространство хранения в узле 2. Но теперь, когда мы разделили хранилище в каждом из узлов, мы зеркально отразим первую часть узла 1 на часть узла 2; а узел 2 делает то же самое, но с узлом 3; а узел 3 делает то же самое, но с узлом 4; и этот процесс продолжается бесконечно до тех пор, пока какой- либо номер оконечного узла не сделает этого с узлом 1, завершающим весь круг, причём каждая из машин обладает RAID 1 для своих данных, разделённых между двумя прочими узлами в качестве его зеркальной пары. Таким образом, мы можем превратить кольцо Сетевого RAID в неопределённо большое.

Что и говорить, такая техника мощная. Но её чрезвычайно громоздко документировать и сопровождать. Когда у вас имеется некий статический кластер, который никогда не изменяется, он может работать хорошо. Но если вы регулярно расширяете или изменяете кластер, это может стать достаточно проблематичным.

DRBD и большинство технологий Сетевого RAID, как правило, обладают хорошей общей производительностью и, что скорее всего более важно, достаточно предсказуемой производительностью. DRBD, по своей природе представляющее конечное блочное устройство, по- существу, является локальным. Для удалённого доступа к DRBD необходимо применять DRBD в качестве строительного блока под некое устройство SAN, которое затем будет удалённо применяться совместно. Конечно, это всего лишь семантика. DRBD всегда является локальным, поскольку для DRBD SAN выступает локальным вычислительным узлом, а интерфейс SAN это ещё один уровень над общеизвестным стеком, а потому хотя SAN и будет удалённым, DRBD будет локальным!

Хотя это и две совершенно различные технологии, Gluster и CEPH обе бесплатны, с открытым исходным кодом и современные решения RAIN, разработанные для Linux, которые допускают высокие уровни надёжности и высокую степень масштабируемости. Оба этих решения предлагают возможность хранения данных локально, по крайней мере, по отношению к рассматриваемому вычислительному узлу. Оба являются очень сложными решениями с множеством вариантов развёртывания. Мы не можем просто предположить, что применение любой технологии говорит нам о том, что такое хранилище будет локальным или удалённым. Локальное приложение, безусловно, является более распространённым, но оба обладают возможностью непосредственно создавать удалённо достижимый и обособленный уровень хранения, доступ к которому осуществляется через сетевую среду, раз они разработаны для этого.

Эти технологии достаточно сложны и полны вариантов для того чтобы мы погрузились в них. Нам обязательно придётся рассматривать их только на очень высоком уровне, хотя для наших нужд этого должно быть и более чем достаточно.

Хранилище RAIN такого рода выступает наиболее распространённым подходом к работе с большими пулами серверов (вычислительных узлов), которые совместно будут применять пул хранения. Этот метод даёт возможность хранилищу быть локальным, автоматически ему выполнять свою повторную балансировку в случае сбоя, но редко гарантирует локальность данных. Хранилище по всей группе это всего лишь пул. Таким образом, может иметься близость к локальности данных, но строгая локальность, как в случае с DRBD отсутствует, но гораздо большую гибкость и лучшее применение в случае с Gluster и CEPH. {Прим. пер.: подробнее о CEPH в наших переводах Полное руководство Ceph, 2е изд Ника Фиска, Packt Publishing, 2019; Изучаем Ceph, 2е изд Энтони Д'Атри, Вайбхава Бхембре, Карана Сингха, Packt Publishing, 2017; Книга рецептов Ceph Карана Сингха, Packt Publishing, 2016; Полная виртуализация. Базовая коммерческая редакция: Proxmox-freeNAS-Zentyal-pfSense Ли Р. Сюрбера, Linux Solutions(LRS-TEK), 2016.}

Дополнительно к тому что встроено или потенциально включается в дистрибутив Linux, вы можете устанавливать множество сторонних компонентов. Почти все эти продукты попадают в категорию RAIN и отличаются стоимостью, сопровождением и возможностями. Некоторые из тех, о которых стоит знать, включают в свой состав LizardFS, MooseFS и Lustre.

Невозможно охватить весь потенциальный ассортимент коммерческих продуктов, которые могут быть доступными или стать таковыми. Хранилище RAIN пребывает в стадии непрерывной разработки и многие поставщики всё ещё выпускают продукты в этой области, но не превращают их в широко доступные. В некоторых случаях вы можете обнаружить коммерческие системы RAIN или RAID, которые доступны только при включении в аппаратуру того или иного типа, либо в какой- то иной продукт. Но все эти системы хранения следуют одним и тем же базовым понятиям и, как только вы разберётесь с тем что они собой представляют и как это может работать, вы сможете применять правильные решения относительно своих систем хранения, даже когда вы и не работали конкретно с такой реализацией.

Слишком просто запутаться при обсуждении хранения и позабыть, что в большинстве случаев хранилище это даже не то, о чём стоит беспокоиться системным администраторам! По крайней мере, не в том смысле, в каком мы подходили к ним.

 

Администратор хранилища

В крупных организациях нередко принимают решение о разделении ответственности за хранение и за системы, поскольку имеется такое большое число связанных с хранением сложностей и нюансов, что наличие выделенной команды под их понимание имеет смысл. Если вы работали в среде Fortune 500, вы, скорее всего, были свидетелем этого.

Некоторые из самых крупных проблем с этим возникают по причине отделения глубоко разбирающихся в рабочих нагрузках сотрудников от каких- то наиболее важных определяющих производительность и надёжность этих рабочих нагрузок факторов. Разделение также зачастую требует чтобы основные архитектурные решения принимались политически, а не технически. Когда вы применяете локальное хранилище, вы не можете каким бы то ни было реалистичным образом разделять команды хранения и систем. По этой причине многие организации часто применяли технически ужасные проектные решения для создания разрозненных навыков в своей организации, причём не задумываясь о том, как это повлияет на рабочие нагрузки. Для такой цели достаточно часто применяется технология SAN.

Вне зависимости от действенности такого подхода, когда он применяется, как правило это означает, что хранилище выводится из-под контроля системных администраторов. Это резко упрощает нашу роль, одновременно ставя нас на колени когда дело доходит до возможности приносить максимальную ценность. Мы можем запрашивать определённые уровни производительности или надёжности и должны верить, что наши потребности будут удовлетворены или что мы, по крайней мере, не будем нести ответственности ха их неудачу.

Точно также принято разделять команды систем и платформ. В такой ситуации мы наблюдаем тот же самый эффект. Команда платформы, которая управляет лежащим в основе систем гипервизором предоставит команде систем ёмкость хранилища, а системы обязаны потреблять то, что им доступно.

В обоих этих ситуациях хранилища абстрагируются от имеющейся системы и предоставляются нам в команду систем просто как слепое блочное устройство (устройства). Когда случается такое,нам всё ещё приходится разбираться с тем как могут работать лежащие в основе компоненты, на какие вопросы отвечать и в самом конце текущего дня всё ещё управлять файловыми системами поверх предоставляемых блочных устройств. Сам интерфейс блочного устройства всё ещё остаётся пасующим интерфейсом от команды неких хранилища или платформы к команде систем.

Дополнительное отдельное замечание: то же самое происходит и с командой платформы. Возможно им придётся брать у команды хранения слепое хранилище, применять его на уровне гипервизора, а затем разделять это блочное устройство на более мелкие блочные устройства для передаче команде систем!

В наши дни большинство систем Linux каким- то образом будут виртуализированы. Нам следует разбираться в хранилище на всём пути вниз по стеку, потому как сам Linux может выступать гипервизором (например, в случае KVM) или применяться для управления гипервизором (как в случае с Xen), либо предоставлять хранилище для гипервизора более высокого уровня (такого как VirtualBox), и во всех таких случаях это Linux, потенциально управляющий всеми сторонами работы с хранилищем. К тому же Linux может применяться для создания устройства SAN или для уровня хранения в каком- либо ином виде. Мы обязаны разбираться с хранилищем внутри и снаружи, но в большинстве ситуаций наши системы Linux будут получать своё хранилище от своего гипервизора, даже если мы и управляем таким гипервизором.

Хотя они и могут вести себя по- разному, большинство людей настраивают гипервизоры так, чтобы они действовали для хранения на уровне LVM. Это слегка особый случай, поскольку они преобразовываются из блочной в файловую систему, а затем обратно в блочную для передачи в соответствующую виртуальную машину, но сама концепция останется прежней. Некоторые настройки гипервизора просто проходят через прямое блочное подключение с лежащим в основе хранилищем, будь то локальный диск, SAN или логический том LVM. Всё это допустимые подходы, которые оставляют виртуальной машине больше возможностей для выбора того, как именно она будет взаимодействовать с самим хранилищем. Но, по большому счёту, когда блочный уровень хранилища завершается гипервизором, преобразуется в файловую систему, создаёт поверх такой файловой системы контейнеры блочного устройства и позволяя виртуальным машинам применять такие устройства в качестве обычных блочных устройств, это именно то, что ожидается от виртуализации, на которую многие люди в действительности ссылаются на такой артефакт подхода к виртуализации как на неотъемлемую часть самой виртуализации, что на самом деле не так.

Вы также можете применять такую технику внутри системы. Такие примеры включают монтируемые типы файлов файловых систем, такие как файлы qcow2, vhdx или iso. Нечто, чм мы занимаемся каждый день, но на самом деле о чём редко задумываемся или осознаём.

Очевидно, что при получении своего хранилища от гипервизора, рассмотрение относительно стандартного (без репликации) локального хранилища, реплицируемого локального хранилища, стандартного (без репликации) удалённые хранилища или реплицируемые удалённые хранилища, все они осуществляются на уровне, отличном от уровня системы, но такие решения всё ещё приемлемы, причём эти решения полностью влияют на то, как в конечном итоге будут работать наши системы.

Мы изучили множество подходов и парадигм абстрагирования хранилища при помощи LVM, RAID и RAIN. Теперь нам необходимо начать думать о том, как мы объединим эти технологии воедино для построения своих собственных решений.

Ничто не создаёт большего риска для наших систем, чем наше хранилище. Это должно быть самом собой разумеющимся, но об этом необходимо сказать. Хранилище это именно то место где мы, как системные администраторы, имеем минимальную возможность изменения ситуации, и это то самое место где мы с наибольшей вероятностью получим отказ и отказ впечатляющий.

Чтобы учитывать риски и возможности мы обязаны понимать весь свой стек хранения и то, как каждый уровень и компонент взаимодействуют друг с другом. Хранилище может показаться ошеломительным, так как имеется множество подвижных частей и дополнительных компонентов.

Мы можем смягчать некоторые из этих ошеломительных впечатлений предоставляя шаблоны проектирования для достижения успеха и понимания того, когда следует рассматривать какие шаблоны.

В архитектуре хранения существуют две оси реально верхнего уровня: сопоставление локального с удалённым и стандартного с реплицируемым.

Естественно, естественно предположить, что для для большинства людей очевидным непосредственным переходом выступает отправная точкой репликации и удалённости. На самом деле это не так. Вероятно, это наименее разумная отправная точка для хранения, поскольку она обладает наименьшую вероятность полезного сочетания факторов.

Поверите или нет, наиболее распространённый подход к проектированию хранилища для компаний любого размера это локальное хранилище без репликации! Имейте в виду, когда мы говорим о реплицируемых архитектурах хранения, это не относится ни к отсутствию резервных копий, ни к локальному или локально реплицируемому (такому как зераклируемый RAID), а относится лишь к тому, а относится лишь к тому, реплицируется ли или нет хранилище в реальном или близком к реальному масштабу времени во второе, полностью обособленную систему.

Когда мы будем рассматривать общий дизайн системы вместо обособленного хранилища, мы снова вернёмся к этому и слегка иначе. Как и большинство вещей в жизни, обычно простота имеет наивысший смысл. Репликация звучит впечатляюще, но репликация стоит денег, и зачастую очень больших, и хорошая репликация часто влияет на производительность, причём потенциально существенно.

 

Репликация бедствия

Распространённой ошибкой при проектировании хранилища является эмоциональное ощущение что чем больше у нас репликаций, тем больше мы защищены от катастрофы. До какой- то степени это так, локальная репликация некоторых файлов при помощи RAID 1 во многом защищает от сбоя отдельного жёсткого диска, а удалённая репликация способна защитить от сбоя всего узла, но ни одна из них не защищает от гораздо более распространённых проблем, таких как случайное удаление файла, злонамеренное уничтожение файлов, повреждение файлов или программы- вымогатели.

Если мы сделаем нечто простое, скажем, удалим файл, чего делать не стоит, то наш мощный механизм репликации немедленно обеспечит удаление по всей системе за одну- две миллисекунды. Вместо того чтобы защищать нас, это может служить механизмом, который повторяет нашу ошибку быстрее, чем мы успеваем отреагировать на неё. Чрезмерные механизмы репликации обычно защищают лишь от аппаратных сбоев и быстро могут приводить к снижению полезного эффекта.

Такой первый уровень RAID может быть очень ценным потому как сбой жёсткого диска остаётся очень реальным риском, а даже малейший сбой диска способен приводить к значительной утрате данных. Однако репликация между узлами защищает лишь от потери всей системы, что встречается гораздо реже. Защита RAID относительно экономична, её реализация часто стоит всего несколько сотен долларов. Репликация узла, однако, потребует значительно большего числа аппаратных средств для достижения репликации, которая стоит тысячи или десятки тысяч долларов за небольшую часть защиты, которую уже не обеспечивает RAID.

Подобный RAID механизм, в особенности RAID 1 (зеркалирование) к тому же чрезвычайно прост в реализации и очень непосредственный. В зеркальном RAID достаточно редко можно встречать вызываемую человеческим фактором утрату данных. Этого нельзя сказать о реплицируемом хранилище между узлами. Существует гораздо больше ошибок и намного выше вероятность того, что человеческая ошибка приведёт к потере данных. Выбирая этот дорогостоящий путь, мы не просто снижаем риски, мы вводим прочие риски, которые также надлежит снижать.

Многие системные администраторы полагают что они не могут применять простое, локальное хранилище без репликации и проблемы с политикой компании нельзя игнорировать. Когда ваша компания намерена играть политикам и винить вас, как системного администратора, даже когда ошибка не ваша, а ваше решение было наилучшим для ведения дел, тогда вы вынуждены принимать не отвечающие прибыльности вашей компании решения. Это совсем не то что подвластно системному администратору.

В качестве системного администратора порой мы можем управиться с подобной политической задачей, представляя (и хорошо документируя) риски и финансовые решения, чтобы продемонстрировать почему решение, которое в конечном счёте могло бы приводить к утрате данных, всё же было верным решением. Ни одно из решений не способно устранять все риски, поскольку системные администраторы всегда принимают решение о том, какой уровень риска попытаться снизить, и с какими финансовыми затратами мы должны это сделать.

 

Оценки риска

Одной из самых тяжёлых, но всё ещё важных, сторон ИТ и в особенности системных администраторов выступает оценка рисков чтобы допускать надлежащее планирование. риску редко обучают ни формально, ни по сути. Это именно та область, в которой почти все предприятия терпят впечатляющий крах, а ИТ, в котором риск играет ключевую роль во всём что мы делаем, обычно остаётся без обучения, ресурсов и сопровождения.

Обучение риску само по себе является карьерой, но здесь можно рассмотреть ряд методов, которые нам надлежит применять постоянно. По своей сути, риск заключается в установлении стоимости, которую мы можем применять в противовес предполагаемой прибыли.

У нас имеются две ключевые стороны риска. Первая это вероятность того, что произойдёт нечто плохое, второе - влияние такого события. Первое мы можем выразить как происходящее X раз в год, если вы сочтёте это удобным. Второе можно отразить в денежном выражении, скажем, это будет стоить 5000$. Если нечто случается раз в десятилетие, то можно сказать, что это 0.1 раза в год. Итак, что- то, что влияет на нас на пять тысяч долларов будет стоить 500 долларов в год. Это до смешного упрощённо, и не совсем так, как работает риск. Но это невероятно полезный инструмент для выражения решений о риске для руководства, когда они хотят чтобы миллионы факторов сводились к единственному конечному числу.

Теперь мы получили свои числа, которые показывают стоимость стратегии смягчения риска. Например, если мы намерены реализовать технологию репликации, которая стоит 300$/ год для лицензирования и требует десяти часов времени системного администратора в год при оплате 120$/ час, это может стать проектом со стоимостью смягчения в 1500$/ год.

В последующие недели требуется смягчение эффективности. На самом деле ничто не является стопроцентным. Но хорошая тратегия репликации может быть эффективной на 95%, а обычная может быть около 65%. С этими числами мы можем провести более сложные математические вычисления.

Мы знаем, что мы рискуем потерять около 500$ в год. Если мы затратим в год 1500$, мы можем с уверенностью в 95% остановить потерю 500$. 500$ * .95 = 475$. Итак, возьмём 1500$ - 475$ = 1025$ убытков в год, вызываемых стратегией снижения рисков. Эти цифры вы можете сообщать финансовому директору. Выполнив эти вычисления, вы должны быть в состоянии показать экономию или защиту, а не потери. Если вы показываете убыток, вам на самом деле стоит избегать данного плана. Это означает, что механизм защиты от рисков, во всех смыслах и целях, представляет собой бедствие просто благодаря своей реализации.

Математика может звучать банально, но среднестатистический системный администратор и даже среднестатистический финансовый директор зачастую отказываются от элементарных вычислений и руководствуются исключительно эмоциями. Применение математики защитит вас. Это означает, что вы сможете пойти к финансовому директору или генеральному директору и отстаивать свою позицию. С математикой не поспоришь. Покажите им расчёты, а если они решат что вычисления не верны, пусть поработают с числами. Если они решат проигнорировать математику, ну, вы понимаете в какой конторе вы работаете и вам и в самом деле следует долго и серьёзно поразмыслить о том, какое будущее ждёт компанию, которая полагает, что прибыль не является их движущим фактором. И если в будущем что- то пойдёт не так, а вас обвинят, вы сможете достать свои вычисления и спросить, раз это было неверным решением, тогда почему мы не обнаружили этого в расчётах, когда принимали решение?

Нет ничего лучше, чем успешно защищать, казалось бы, безумное решение, подкреплённое математикой. Покажите что вы делаете свою работу наилучшим образом. Ничего не говорите просто так, не делайте необоснованных заявлений. Воспользуйтесь вычислениями и докажите почему вы принимаете решения. Поднимите состояние принятия решения от догадок до научного уровня.

Не со всеми рабочими нагрузками можно обращаться так просто. Но гораздо больше, чем это обычно предполагается. Именно это должно быть вашим стандартным предположением, если у вас нет солидных расчётов чтобы показать обратное. Или же вы имеете дело с ситуацией, выходящей за рамки математики, например, с системами жизнеобеспечения, когда время безотказной работы и надёжность важнее, чем это можно описать деньгами. В противном случае применяйте вычисления.

Этот простейший из всех подходов к хранению легко представить как кирпич. Он прост, надёжен, он просто создаёт резервную копию и восстановление, его легко понять и сопровождать. Сегодня это решение настолько действенно, в особенности с современными технологиями хранения и аппаратного обеспечения, что я утверждаю, что оно подходит для 85-90% всех производственных рабочих нагрузок, причём независимо от размера компании, и не менее 99% рабочих нагрузок для малого бизнеса.

Те рабочие нагрузки и случаи, которые не имеют смысла для описанной выше простой архитектуры, почти всегда оказываются в этой категории реплицируемого локального хранилища (RLS, replicated local storage). RLS обеспечивает хранилище с высокой доступностью и с высокой производительностью по разумной цене. Ничто не будет соответствовать производительности и стоимости непосредственного локального хранилища, о котором мы упоминали вначале, но когда вам требуется более высокая доступность и лучшая надёжность, чем то что может предоставить такое решение, это почти наверняка решение для вас.

RLS предоставляет наивысший уровень доступной надёжности, потому что он обладает большим числом подвижных частей. Удалённое решение высокой доступности обязательно должно быть связано с расстоянием, кабелями и сетевыми протоколами как минимальными дополнительными компонентами и, как правило, с сетевым оборудованием (например, с коммутаторами), причём помимо связанных с RLS рисков. Помните, что желающие добиться истинной высокой доступности решения удалённого хранения должны применять локально в своём собственном кластере RLS, а затем сделать этот кластер хранилища доступным удалённо по сети с тем, чтобы вы получили все потенциальные проблемы RLS плюс накладные расходы и риски, вызванные технологией удалённого доступа.

Если непосредственное удалённое хранилище без удалённой репликации берёт на себя девяносто процентов всех рабочих нагрузок, то стандартная RLS берёт девяносто процентов остающихся (вместе они должны занимать порядка девяносто девяти процентов). При правильном планировании эти два варианта настолько просты и экономичны, а также и безопасны, что их просто невозможно убить в обычных условиях. Это ваш перерыв на бутерброд с маслом.

 

Альтернатива надёжности хранения

Хотя RLS может и показаться абсолютным венцом всему тому, что защищает хранилище, в действительности это не так. Это замечательно, когда для обеспечения надёжности вам приходится полагаться на соответствующий уровень хранения. Но в этом отношении, RLS это всего лишь временное решение или заплатка, а не окончательное решение.

В идеальном мире, с такими предметами как базы данных, у нас имеются механизмы хранения, которые выступают уровнем выше, нежели наш фактический уровень хранения. Система управления базами данных способна гораздо лучше поддерживать доступность и координировать репликацию данных между узлами, чем механизм слепой блочной репликации. Имеет смысл выполнять репликации там, где приложение обладает таким интеллектом.

В идеале приложения должны применять свои базы данных в качестве собственного уровня хранения и надёжности, позволяя знающим как применяются хи данные интеллектуальным системам применять реплицирование того, что имеет смысл. Базы данных являются одним из самых идеальных механизмов репликации, ибо они знают какие данные у них имеются и способны принимать для них верные решения.

По этой причине многие корпоративные приложения вообще не применяют какие- либо формы хранения или даже репликации систем. Применение ненадёжных систем с обладающим высокой надёжностью приложением это надёжная стратегия, которая даёт вам преимущества, которые вы не можете получить никаким иным способом. По этой причине мы порой можем просто игнорировать потребности в высокой доступности на уровне сырого хранилища и просто сосредоточиться на производительности.

Данная архитектура крайне популярна, поскольку она проверяет все блоки при продаже: дороговизну, риски и путаницу. И в самом деле, продавцы предлагают этот вариант чаще любого иного, поскольку он создаёт такое обилие способов выставления клиенту счёта за дополнительные услуги, перекладывая всю ответственность на самого клиента.

Все архитектуры обладаю более или менее законным местом в экосистеме, и эта не является исключением. Но прежде чем мы сформулируем вариант применения, нам необходимо указать в чём именно состоят его преимущества: удалённое хранилище без репликации медленнее, рискованнее и дороже (на первый взгляд), чем механизмы локального хранения. Где мы можем сыскать ценность для такого решения?

Основные преимущества состоят в лабораторных, тестовых и прочих средах, в которых значимость надёжных данных не существенна, но мы способны извлекать максимальную выгоду из больших сред, в которых можно разумно выделять пространство для хранения чтобы добиваться максимальной экономии средств в бо́льших масштабах.

Почти каждая крупная среда нуждается в подобном хранилище в некий момент сбора рабочих нагрузок. Основной момент состоит в том, чтобы определить где такое сочетаний потребностей разумно и не пытаться применять его там, где оно неуместно. Поскольку такой тип хранилища не затратен при большом масштабе (но возмутительно дорог при малом размере), и поскольку управляющие столь часто ошибочно принимают удалённое совместное хранилище за волшебную коробку, которая не подведёт, его часто применяют там, где он применим минимально. Это не волшебство, это плохая технология для большинства промышленных рабочих нагрузок и её надлежит выбирать исключительно с большой осторожностью.

Эмпирическое правило состоит в том, что вам надлежит применять такой тип хранилища только тогда, когда вы можете убедительно доказать что оно имеет смысл, то есть, что даже стандартная надёжность и производительность не представляют ценности. Когда у вас имеются какие- то сомнения или когда у вашей организации имеются некие колебания, прежде чем ошибиться с этой, что означало бы максимальный риск, возьмите иную архитектуру хранения. Ошибка с производительностью это мягкий сбой, её просто исправить после обнаружения и обычно она пребывает в стороне от критически важной сферы, если уж вы её допустили. Утрата данных это жёсткий сбой, когда ошибка вовсе не аккуратна, а является катастрофой и у вас мало возможностей исправить её впоследствии.

Хотя для определения всей архитектуры целиком требуется гораздо больше чем просто решения плохого хранилища, удалённое хранилище без репликации это основа популярного решения, применяемого производителями и торговыми посредниками, которое они обычно именуют архитектурой 3-2-1 и тем, что практикующие ИТ профессионалы называют Перевёрнутой пирамидой рока.

Такая архитектура традиционно широко применяется, однако с немалым отрывом это менее всего подходящая когда бы то ни было архитектура для промышленного применения. Она медленная, сложная, дорогая и сопряжена с самыми высокими рисками. Она имеет смысл в первую очередь в лабораторных условиях, когда воссоздание подлежащих хранению данных не больше чем затратно по времени. Данная архитектура и в самом деле разработана с учётом потребностей типично не промышленных рабочих нагрузок.

Наша последняя рассматриваемая архитектура является самой большой из всех. Удалённое хранилище с репликацией. Может показаться, что это будет та архитектура хранения, которую вы обнаружите в каждом предприятии, и хотя она и вовсе не редкость, она встречается гораздо реже чем вы думаете.

Удалённое хранилище с репликацией является самым дорогостоящим при реализации в небольших масштабах, но может становиться вполне доступным при больших размерах. Оно отличается большей сложностью по сравнению с RLS (что означает меньшую надёжность) и более низкой производительностью по сравнению с RLS или непосредственным локальным хранилищем, а потому имеет смысл только тогда, когда экономия стоит на первом месте, но некая степень надёжности всё же гарантируется. Это слегка нишевое решение.

Принимая в учёт то, что нашими двумя локальными архитектурами было предоставлено девяносто девять процентов развёртываний рабочих нагрузок (конечно, лично мной), эта архитектура получает основную часть последнего остающегося процента, по крайней мере, в промышленной среде.

 

Самая безопасная система всего лишь безопасна

Одна из моих самых драматичных историй за десятилетия работы системным администратором связана со временем, когда я работал консультантом в университетской библиотеке. Меня привлекли для работы с крупными базами данных в этом магазине с двумя администраторами. Старший администратор уехал в отпуск и осталась лишь младший администратор. В этой среде применялась система SAN с высокой степенью избыточности и с высокой доступностью, от которой зависели все системы. Данная система обладала чрезвычайной защитой начиная с ИБП вплоть до генераторов и избыточности оборудования, и всё это стоило больших затрат.

Пока я там был, младший администратор решила провести техническое обслуживание SAN и по какой-то причине случайно кликнула по удалению всех томов в этой SAN. Естественно, это был несчастный случай, но крайне неосторожный, выполненный кем-то, кто предполагал что все возможные сценарии отказа тщательно защищены. Однако вся высокая доступность, вся избыточность, все эти специальные технологии не помогли устранить эту простую человеческую ошибку.

По мановению единственного щелчка мышью исчезли все вычислительные системы библиотеки. Все приложения, все базы данных, все пользователи, все журналы. Всё это. Всё зависело от единственной системы хранения, причём эта система могла быть выключена или, в данном случае, удалена, практически без усилий кого бы то ни было, у кого имелся к ней доступ. Все яйца находились в одной корзине, которая хоть и была очень прочной, имела большое отверстие и была способна переворачиваться вверх дном.

Что ещё хуже, младший системный администратор не была эмоционально готова к такому событию и была столь напугана утратой своей работы, что её пришлось госпитализировать, а весь потенциальный ИТ персонал, который мог бы вмешаться чтобы помочь, вместо этого был занят тем, чтобы вызвать для неё скорую помощь. Из- за плохого технологического планирования и по причине плохого планирования персоналом, легко предотвратимая катастрофа, которая должна была бы превратиться лишь в незначительное происшествие восстановления, превратилась в гигантский выход из строя. К счастью, имелись хорошие резервные копии, и систему удалось относительно быстро восстановить. Но это хорошо продемонстрировало насколько много мы вкладываем средств в защиту от механических аварий, и как мало мы обращаем внимания на человеческие слабости, и действительно, именно человеческая ошибка с гораздо большей вероятностью способна стать причиной катастроф, нежели аппаратный сбой.

Архитектуры хранения и риски это самая сложная часть проектирования хранилища. Углубление в подробности файловой системы, как правило, для нас, системных администраторов, доставляет удовольствие и несёт очень небольшой риск. Если мы выберем EXT4 когда BtrFS была бы лучше, вероятно, штраф будет номинальным, таким, что мы никогда не будем ожидать, что кто- либо когда- либо обнаружит, что мы приняли не идеальное решение. Однако выбор неверной архитектуры хранения может приводить к огромным затратам, большому времени простоя или значительной утрате данных.

Нам и в самом деле требуется определённое время чтобы разобраться с потребностями своей компании и с рабочими нагрузками. Насколько приемлемым является риск, какая производительность нам необходима, как удовлетворить все потребности при оптимальных затратах. Если у нас нет ответов, нам нужно их определить.

Как всегда, наилучшая практика состоит в том, чтобы уделить время изучению всех потребностей компании, исследовать все доступные стороны и применить их. Но это очень трудно выполнить на практике. Некоторые эмпирические правила, которые помогли бы нам, придутся очень кстати.

Попытка выделить наилучшие практические приёмы хранилища довольно сложна. На самом верхнем уровне, самое фундаментальное правило хранения состоит в том, что не бывает ярлыков, вам требуется понимать все стороны своей инфраструктуры данных, разбираться в рабочих нагрузках и применять такие объединённые познания, которые позволяют при невосприимчивости к свойственного предприятию риска определять идеальные рабочие нагрузки.

Следуя далее, устоявшиеся практики включают:

В качестве системного администратора вы не часто можете иметь дело с решениями по проектированию системы хранения. Но сколь редким это бы ни было, решения по проектированию системы хранения данных оказывают наиболее существенное влияние на нашу систему в долгосрочной перспективе по сравнению с любыми прочими принимаемыми нами решениями. Чтобы действительно определить что требуется для каждой рабочей нагрузки, не спешите.

Нам следует сделать шаг назад и собрать воедино некий образец того как эти части могут составляться вместе в ситуации из реальной жизни. Мы не можем разумно привести примеры для всего распространённого, не говоря уже о правдоподобном, но, надеюсь, мы сможем дать представление о том, что мы обсуждали в этой главе для того, чтобы собрать для вас всё вместе.

Чтобы всё было достаточно простым, я буду подходить к своему занятию как можно более обобщённо с абсолютно самой распространённой настройкой, применяемой в малом и среднем бизнесе. Или, по крайней мере, с тем, что, скорее всего, должно выступать для них наиболее распространённой установкой.

Как правило, небольшие предприятия выигрывают от того, что их решения достаточно простые. Не обладая большим числом опытного персонала и часто подвергаясь высокому риску текучести кадров, малые предприятия нуждаются в системах, которые требуют меньшего сопровождения и которые могут легко обслуживаться консультантами или персоналом, которые не обладают знаниями об их среде.

Для сред такого вида, а также для многих более крупных сред, важны аппаратные RAID с возможностью горячей и слепой замены дисков. Это позволяет обслуживающим оборудование специалистам выполнять задачи без необходимости осуществления системного администрирования. Это становится чрезвычайно важным при работе с совместным размещением или при прочих удалённых объектах. В таких ситуациях некто из ИТ отдела вообще может не иметь возможности принимать физическое участие.

итак, мы начинаем с некоторых общих предположений. На физическом уровне у нас имеется восемь жёстких дисков. Это могут быть шпиндельные диски, SSD, NVMe, любые блочные устройства. Это в действительности не имеет значения. Важно то, что у нас их несколько, но мы хотим чтобы все они действовали как единое целое.

Итак, добавляем к этому аппаратный RAID- контроллер. Этот RAID- контроллер мы применяем для подключения всех дисков и настраиваем его на соответствующий уровень RAID. Это может быть любое число вариантов, но для данного примера мы допустим, что все они пребывают в RAID 10.

С самого начала своего примера, даже не установив Linux или чего- то в этом роде, мы воспользовались аппаратными средствами своей системы для реализации своих первых двух уровней хранения! Сами физические устройства и первый уровень абстракции.

Мы не будем показывать здесь физического процесса вставки дисков, это чисто ручной процесс и, скорее всего, поставщик вашего сервера уже сделал это за вас.

Что касается настройки самого RAID, всякий контроллер и его производитель слегка отличаются, но основы одни и те же, а сама задача всегда предельно проста. Именно в этом и состоит основная цель RAID- контроллера - свести к абсолютному минимуму необходимых для RAID операций объём знаний и планирования, причём как на начальной стадии, так и на этапах сопровождения. Для нашего примера в данном случае, чтобы упростить демонстрацию, мы намерены предположить, что имеем дело с одним массивом, из которого и работает наша операционная система, чтобы нам было проще показать некоторые шаги из командной строки. Но это всего лишь пример.

Помните, что аппаратный RAID отличается для каждого производителя и потенциально для каждого продукта у производителя. Поэтому вам всегда требуется знать в точности с каким именно продуктом вы работаете.

К тому же нам следует отметить, что для конкретного RAID контроллера каждый подключаемый к нему накопитель это блочное устройство. Это именно тот уникальный случай, когда интерфейс блочного устройства, притворяющийся физическим жёстким диском и в самом деле является жёстким диском! В каждом последующем случае для реализации интерфейса жёсткого диска мы будем применять программное обеспечение, но представляемый нами диск будет логическим, а не физическим:

=>ctrl slot=0 create type=ld drives=2I:1:5,2I:1:6,2I:1:7,2I:1:8 raid=1+0
		

Это действительный синтаксис для RAID контроллера из реального мира. Обычно вы выполняете эту задачу из графического интерфейса. Однако порой вы пожелаете воспользоваться утилитой командной строки. Когда это возможно, я работаю с командной строкой, это лучше повторять и намного проще документировать.

После прохождения данного этапа первоначального конфигурирования оборудования далее мы продолжим со специфичной для Linux частью этого примера.

В имеющейся файловой системе /dev аппаратные контроллеры обычно создают свои собственные соглашения об именовании. В случае с нашим примером, наш контроллер применяет синтаксис cciss и создаёт в данной системе устройство c0d1. Всё это меняется в зависимости от самого управления и применяемых вами настроек.

Далее мы собираемся создать некий уровень логического тома поверх своего уровня RAID чтобы допускать для нас большую гибкость в своей системе хранения. Для этого нам надлежит начать добавлять вновь создаваемое устройство в систему LVM (Диспетчера логических томов) Linux в виде физического устройства. Мы выполняем это при помощи команды pcvreate и пути к своему новому устройству:

# pvcreate /dev/cciss/c0d1
		

Очень быстро и просто. Теперь наша подсистема Диспетчера логических томов осведомлена о нашем новом устройстве массива RAID. Однако, конечно же, всё что известно LVM и о чём он заботится, это то, что это блочное устройство. LVM способен обнаружить что это а самом деле именно RAID массив, но это не имеет значения. Суть здесь в том, что он абстрагирован и может применяться тем же самым образом, вне зависимости от того чем он является. Все характеристики скорости, ёмкости и безопасности инкапсулированы на уровне RAID, и теперь мы можем представлять его себе по мере продвижения вперёд исключительно как жёсткий диск.

Другим интересным моментом является то, что при применении аппаратного RAID контроллера это абстрактное и виртуальное представление жёсткого диска является лишь логическим жёстким диском, однако в качестве блочного устройства оно фактически выступает физическим! Я знаю, сногсшибательно. Это и в самом деле аппаратное средство, просто это не аппаратный жёсткий диск. На мгновение задумайтесь об этом.

Раз наш RAID массив находится под управлением LVM, мы можем добавить этот накопитель в группу томов. В данном примере мы добавим его в новую группу томов, которую мы создадим исключительно для этой цели своего примера. Мы присвоим этой новой группе имя vg1. Вот образец команды, выполняющей это:

# vgcreate vg1 /dev/cciss/c0d1
		

Отлично, теперь мы предпримем что- нибудь. Вся ёмкость отдельных физических жёстких дисков, объединённых нашим RAID контроллером в один логический накопитель под управлением Диспетчера логических томов, теперь пребывает в пуле ёмкости или в группе томов, где мы можем начать выделять действительно полезные подмножества этого объёма для применения в своём сервере.

После создания группы томов остаётся лишь создать фактические логические тома. Помните, что логические тома заменили собой разделы в качестве основного средства деления блочного устройства на употребляемые части, которыми мы можем пользоваться. Для своего примера мы выполним самую простую вещь и сообщим системе LVM создать лишь один логический том наибольшего размера; то есть воспользовавшись 100% доступной ёмкости группы томов (которая в настоящее время используется на 0%, ибо это самое первое что мы с н ей предпримем):

# lvcreate -l 100%FREE -n lv_data vg1
		

Данная команда предписывает LVM создать новый логический том, применяя 100% доступного свободного пространства в группе томов vg1 и назвать свой новый логический том lv_data. Вот и всё. Теперь у нас имеется логический том, который мы можем применять! Должно быть очевидно, что мы могли бы сделать логический том меньшего размера, скажем, в 50%, а затем сделать второй, также из 100% от того что осталось после этого, чтобы получить два логических тома одинакового размера.

Помните, что подобная той, что применяется здесь, в Linux, система Диспетчера логических томов предоставляет нам гибкость, которой нам зачастую не хватало бы, если бы мы применяли файловую систему непосредственно к физическим дискам или даже к виртуальному диску, представленному аппаратным обеспечением RAID- контроллера. Например, система LVM позволяет нам добавлять в группу физических томов больше физических устройств, что даёт нам больше возможностей для создания логических томов. Это позволит нам изменять размер отдельных логических томов, увеличивая или уменьшая их. Диспетчер логических томов также позволит нам выполнить снимок логического тома, что очень полезно для создания механизма резервного копирования или подготовки к рискованному изменению системы, чтобы мы могли быстро вернуться обратно. LVM выполняет очень важные вещи.

Теперь, когда создан lv_data, нам в большинстве случаев потребуется отформатировать его при помощи файловой системы чтобы превратить его в полезный по- настоящему. Мы будем выполнять форматирование при помощи XFS. В реальном мире в наши дни XFS, скорее всего, будет рекомендованной файловой системой для нужд общего назначения:

# mkfs.xfs /dev/vg1/lv_data
		

Очень просто. Через несколько секунд мы должны получить полностью отформатированный логический том. Применяя форматирование файловой системы, мы останавливаемся на цепочке интерфейсов блочных устройств и теперь представляем интерфейс файловой системы, что представляет собой изменение, позволяющее приложениям применять хранилище стандартным образом вместо использования блочных устройств, применяемых компонентами системы хранения.

Естественно, необходим наш последний шаг, нам следует смонтировать свою новую файловую систему в некую папку для чтобы допустить её применение:

# mkdir /data
# mount /dev/vg1/lv_data /data
		

Вот и всё! Мы просто реализовали систему хранения на основе абстракции со множеством уровней для одного из наиболее применимых сценариев систем. Мы построили файловую систему XFS поверх логического тома Диспетчера логических томов, управляющего поверх аппаратного контроллера RAID поверх множества индивидуальных физических жёстких дисков.

По той причине, что каждый уровень применяет интерфейс блочного устройства, мы могли бы смешивать и сочетать гораздо больше дополнительных функциональных возможностей. Например, применение двух RAID- контроллеров и объединение их ёмкости со своей группой томов. Или создание нескольких групп томов. Мы смогли бы сделать много логических томов. Мы смогли бы воспользоваться программным RAID (именуемым в Linux MD RAID) для создания RAID применяя получаемый от двух RAID контроллеров вывод! Небеса - это реальный предел, но практичность удерживает нас на земле.

В данный момент, если вы cd /data, вы сможете воспользоваться новой файловой системой так, как если бы она всегда была там. И это именно новая файловая система, то что она была построена на всех этих уровнях абстракции, что существует множество физических устройств, превращает всю эту магию в полностью скрытую от вас на данный момент. Это просто работает.

В прошлом, если бы это был 2004 год, мы бы обычно останавливались здесь и говорили, что описали как, скорее всего, будет выглядеть реальный сервер, когда он будет хорошо реализован. Но сейчас далеко не 2004 год, и нам действительно нужно поговорить о том, как мы, вероятно, увидим реализацию своего хранилища в наиболее распространённых ситуациях. Итак, сегодня нам следует подумать о том, как наши уровни виртуализации будут применять это хранилище, потому как тут всё становится ещё интереснее.

Допустим, что наша файловая система /data, которую мы только что создали, будет применяться для хранения образов дисков нескольких виртуальных машин. Конечно, эти образы дисков - всего лишь отдельные файлы, которые мы храним в своей файловой системе. Очень просто. Ничем не отличается от создания и хранения в /data текстового файла (за исключением того, что обычно образы дисков виртуальных машин немного больше).

Что отлично в образе диска (это может быть QCOW, VHD, ISO или что- то ещё), так это то, что они находятся поверх файловой системы, но при открытии специальным драйвером, который способен их считывать, они опять таки представляют собой блочный интерфейс! Это так. Мы перешли от блоков к блокам, блокам, блокам, файловой системе и снова к блокам! В некоторых особых случаях мы даже можем не пользоваться гипервизором, а применять этот новый файл блочного устройства где- нибудь в своём обычном сервере. Windows обычно вытворяет всё это с файлами VHD, как средством передачи данных при определённых обстоятельствах. MacOS превращает это в стандартное средство создания пакетов установки. В Linux это менее распространено, но также доступно.

Но допуская что мы делаем нечто обычное, мы предположим, что мы пользуемся гипервизором, почти наверняка, KVM, и что работающие под KVM виртуальные машины будут применять хранилище файлов дисковых образов в нашей недавно созданной файловой системе. В этом случае, многое из того, что мы проделали здесь, скорее всего, снова произойдёт внутри такой виртуальной машины.

Некоторый части было бы не очень разумно воссоздавать. Физические диски уже управляются физическим RAID- контроллером. Скорость, ёмкость и надёжность хранилища уже установлены этой системой и не нуждаются тут в дублировании. Стандартный подход состоит в том, что один файл образа диска должен быть представлен работающей в виртуальной машине операционной системе, причём как единое блочное устройство. Ничем не отличается от того, как наша операционная система была представлена своим блочным устройством из аппаратного RAID- контроллера.

Теперь внутри своей виртуальной машины мы часто будем выполнять одно и то же упражнение. Добавляем представленное блочное устройство в качестве физического тома LVM. Затем мы добавляем этот физический том в группу томов. После этого мы выделяем один или несколько логических томов из этой группы томов. Далее мы форматируем такой логический том с выбранной нами файловой системой и монтируем его. Конечно, как правило, многое из этого выполняется не вручную, как мы это сделали здесь, а вместо этого автоматизируется весь процесс установки.

Мы можем добавлять дополнительные шаги, такие как применение MD RAID. Или же мы можем применять меньше, например, полностью пропуская LVM. Мы могли бы выполнить в точности все те же действия, воспользовавшись только одним жёстким диском и не применяя RAID- контроллер. Это было бы гораздо менее мощно физически, но все примеры будут работать совершенно одинаково на техническом уровне. Мы могли бы применять LVM в физической машине, но не в виртуальных машинах, или наоборот! Гибкость имеется чтобы выполнять то, что необходимо. Всё дело в понимании того как блочные устройства могут быть разнесены по уровням, как файловая система размещается в блочном устройстве и как блочные устройства способны превращать обратно в блочные устройства!

Абстракция и инкапсуляция удивительно мощные инструменты в нашем арсенале ИТ, и редко они бывают столь ощутимыми.

Раз вы дожили до конца этой главы и всё ещё следуете за мной, поздравляю, мы сделали это! Когда речь заходит о системном администрировании, хранилище имеет большое значение и, вероятно, никакая иная управляемая вами область не сможет принести вашей организации столько пользы.

Опираясь на понятия блочных устройств, методов абстракции, файловых систем и их интерфейсов, мы рассмотрели основы хранения данных, а также воспользовались этими концепциями для изучения избыточности множества устройств и того, как её можно применять для создания сложных и надёжных хранилищ данных, а также для того, как для удовлетворения любых потенциальных потребностей может обрабатываться доступ к хранилищу через устройства. Моя цель здесь состояла в том, чтобы снабдить вас знаниями, необходимыми для самостоятельного тщательного обдумывания своих потребностей в хранении для любой заданной рабочей нагрузки, а также понимание технологий доступности и того, как вы можете пользоваться ими для наиболее действенного достижения этих целей.

Никогда больше вам не следует рассматривать хранилище в качестве волшебного чёрного ящика или сложной задачи, за которую вы опасаетесь взяться. Вместо этого вы можете рассматривать хранилище как возможность проявить себя и продемонстрировать как можно применять надлежащие передовые методы системного администрирования, чтобы выводить на максимум любые стороны хранения, наиболее важные для вашей рабочей нагрузки, не просто забрасывая проблему деньгами или, что ещё хуже, просто игнорируя её и надеясь, что вы сможете отыскать другую работу когда всё развалится.

В своей следующей главе мы рассмотрим системную архитектуру на ещё более высоком уровне. Там будут повторяться многие из наиболее интересных концепций из данной главы. Архитектура системы очень сильно зависит от архитектуры хранения, а многие прочие парадигмы резервирования и защиты системы являются общими. Может оказаться очень приятным обнаружить как хорошие элементы проектирования системы хранения способны приводить к реально высокопроизводительному, обладающему высокой доступностью и экономичному конечному решению.