Backblaze Хостинг

Статистика жесткого диска на 2019 год
По состоянию на 31 декабря 2019 года у Backblaze было 124 956 вращающихся жестких дисков. Из этого числа было 2229 загрузочных дисков и 122 658 дисков с данными. В этом обзоре рассматривается частота отказов жесткого диска для моделей дисков данных, работающих в наших центрах обработки данных. Кроме того, мы посмотрим, как работают наши диски емкостью 12 и 14 ТБ, а также познакомимся с новыми дисками емкостью 16 ТБ, которые мы начали использовать в четвертом квартале. По пути мы будем делиться наблюдениями и взглядами на представленные данные, и мы надеемся, что вы сделаете то же самое в комментариях.

Показатели отказов жесткого диска 2019 года
В конце 2019 года компания Backblaze провела мониторинг 122 658 жестких дисков, используемых для хранения данных. Для нашей оценки мы исключаем из рассмотрения те накопители, которые использовались в целях тестирования, и те модели накопителей, для которых у нас не было как минимум 5000 рабочих дней в течение 4 квартала (см. Примечания и замечания, почему). Это оставляет нам 122 507 жестких дисков. В таблице ниже показано, что произошло в 2019 году.



Примечания и наблюдения
Было 151 диск (122 658 минус 122 507), которые не были включены в список выше. Эти накопители либо использовались для тестирования, либо не имели по крайней мере 5000 рабочих дней в четвертом квартале 2019 года. Ограничение в 5000 рабочих дней исключает те модели накопителей, в которых у нас ограниченное число дисков, работающих в течение ограниченного числа дней в течение периода. наблюдение. ПРИМЕЧАНИЕ. Данные обо всех дисках, дисках данных, загрузочных дисках и т. Д. Доступны для загрузки на веб-странице данных теста жесткого диска.

Единственной моделью накопителя, которая не имела сбоев в течение 2019 года, была модель Toshiba 4 ТБ, модель MD04ABA400V. Это очень хорошо, но выборка данных все еще немного мала. Например, если бы в течение года был только 1 (один) сбой диска, Годовая частота отказов (AFR) для этой модели Toshiba была бы 0,92% — все еще отлично, а не 0%.

Привод Toshiba 14 ТБ, модель MG07ACA14TA, работает очень хорошо при AFR 0,65%, что соответствует показателям, установленным накопителями HGST. Со своей стороны, накопители Seagate 6 ТБ и 10 ТБ продолжают показывать хорошие результаты с годовым уровнем отказов 0,96% и 1,00% соответственно.

AFR для 2019 года для всех моделей накопителей составлял 1,89%, что намного выше, чем в 2018. Об этом мы поговорим позже в этом обзоре.

Помимо графика 2019 года — «скрытые» модели дисков
Есть несколько моделей накопителей, которые не попали в таблицу 2019 года, потому что они не записали достаточное количество дней в эксплуатации. Мы хотели потратить несколько минут, чтобы пролить свет на эти модели накопителей и их направление в нашей среде.

Диски Seagate 16 TB
В четвертом квартале 2019 года мы начали квалификацию дисков Seagate на 16 ТБ, модель: ST16000NM001G. На конец 4-го квартала у нас было 40 (сорок) накопителей, что в общей сложности составляло 1440 рабочих дней, что значительно ниже порогового значения в 5000 дней для накопителя в 4-м квартале, поэтому они не составили график 2019 года. В Q4 было 0 (ноль) сбоев, что делает AFR 0%, хороший старт для любого привода. Предполагая, что они продолжают проходить наш процесс аттестации, они будут использованы в проекте миграции на 12 ТБ и при необходимости увеличат емкость в 2020 году.

Диски Toshiba 8 ТБ
В 4 квартале 2019 года было 20 (двадцать) накопителей Toshiba 8 ТБ, модель HDWF180. Эти диски были установлены в течение почти двух лет. В четвертом квартале у них было только 1840 рабочих дней, что ниже порогового значения для отчетов, но срок службы у них составляет 13 994 рабочих дня с отказом только одного диска, что дает нам AFR 2,6%. Нам нравятся эти диски, но к тому моменту, когда они были доступны нам в количестве, мы могли купить диски по 12 ТБ при той же цене за ТБ. Больше плотности, та же цена. Учитывая, что мы переходим на диски емкостью 16 ТБ и более, мы, скорее всего, не будем покупать эти диски в будущем.

Диски HGST 10 ТБ
В эксплуатации находится 20 (двадцать) накопителей HGST 10 ТБ, модель: HUH721010ALE600. Эти диски находились в эксплуатации чуть более года. Они находятся в том же хранилище Backblaze, что и диски Seagate 10 ТБ. За 4 квартала накопители HGST записали всего 1840 дней, а с момента установки — 8 042. Было 0 (ноль) сбоев. Как и в случае с Toshiba 8 ТБ, приобретение большего количества этих 10 ТБ накопителей маловероятно.

Диски Toshiba 16 ТБ
Вы не найдете их в статистике за четвертый квартал, но в первом квартале 2020 года мы добавили 20 (двадцать) дисков Toshiba объемом 16 ТБ, модель: MG08ACA16TA. Они записали в общей сложности 100 дней вождения, поэтому говорить о чем-либо кроме отчета в первом квартале 2020 года слишком рано.

Сравнение статистики жестких дисков на 2017, 2018 и 2019 гг.
В приведенной ниже таблице сравниваются годовые показатели отказов (AFR) для каждого из последних трех лет. Данные за каждый год включают только этот год и модели приводов, представленные в конце каждого года.



Восходящая АФР в 2019 году
Общий AFR за 2019 год значительно вырос в 2019 году. Около 75% различных моделей приводов испытали увеличение AFR с 2018 по 2019 год. За этим ростом стоят два основных фактора. Во-первых, кажется, что накопители на 8 ТБ как группа испытывают кризис среднего возраста по мере взросления, причем каждая модель демонстрирует наибольший зарегистрированный процент отказов. Хотя ни один из показателей не является причиной для беспокойства, они дают примерно одну четверть (1/4) рабочих дней в общем объеме, поэтому любое увеличение их частоты отказов повлияет на общее количество. Второй фактор — накопители Seagate на 12 ТБ, эта проблема активно решается в рамках проекта миграции на 12 ТБ, о котором сообщалось ранее.

Миграция замедляется, а рост — нет
В 2019 году мы добавили 17 729 новых сетевых дисков. В 2018 году большинство из 14 255 добавленных дисков были связаны с миграцией. В 2019 году менее половины новых накопителей предназначались для миграции, а остальные использовались для новых систем. В 2019 году мы сняли с эксплуатации 8 800 дисков на общую сумму 37 петабайт и заменили их на 8 800 дисков, все 12 ТБ, что составляет около 105 петабайт, а затем в 2019 году мы добавили еще 181 петабайт хранения с использованием дисков 12 и 14 ТБ.

Drive Разнообразие
Разнообразие производителей по маркам накопителей немного увеличилось в 2019 г. В 2018 г. накопители Seagate составляли 78,15% накопителей в эксплуатации, а к концу 2019 г. этот показатель снизился до 73,28%. HGST снизился с 20,77% в 2018 году до 23,69% в 2019 году, а Toshiba увеличилась с 1,34% в 2018 году до 3,03% в 2019 году. В 2019 году в центре обработки данных не было накопителей с фирменной символикой Western Digital, но по мере того, как WDC производил ребрендинг новых более крупных Емкость дисков HGST, мы скорректируем наши цифры соответственно.

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



Данные о жестком диске
Полный набор данных, использованный для создания информации, использованной в этом обзоре, доступен на нашей странице «Тестовые данные жесткого диска». Вы можете скачать и использовать эти данные бесплатно в своих целях. Все, что мы просим, — это три вещи: 1) вы цитируете Backblaze в качестве источника, если вы используете данные, 2) вы соглашаетесь с тем, что несете полную ответственность за то, как вы используете данные, и 3) вы не продаете эти данные кому-либо; это бесплатно.

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

Удачи и дайте нам знать, если найдете что-нибудь интересное.

По состоянию на 30 сентября 2019 года у Backblaze было 115 151 вращающихся жестких дисков, распределенных по четырем центрам обработки данных на двух континентах. Из этого числа было 2098 загрузочных дисков и 113 053 дисков с данными. Мы посмотрим на частоту отказов жестких дисков в течение срока службы моделей накопителей данных, которые в настоящее время работают в наших центрах обработки данных, но сначала мы рассмотрим события, которые произошли в Q3, которые потенциально повлияли на статистику накопителей за этот период. Как всегда, мы опубликуем данные, которые мы используем в этих отчетах, на нашей веб-странице с тестовыми данными жесткого диска, и мы с нетерпением ждем ваших комментариев.
www.backblaze.com/b2/hard-drive-test-data.html

Статистика жесткого диска за 3 квартал 2019 года
На этом этапе в предыдущих отчетах по статистике жестких дисков мы раскрывали квартальную таблицу статистики жестких дисков. На этот раз мы представим только таблицу Lifetime Hard Drive Failure, которую вы можете увидеть, если перейдете к концу этого отчета. Для таблицы Q3 данные, которые мы обычно используем для создания этого отчета, могли быть косвенно затронуты одной из наших служебных программ, которая выполняет проверки целостности данных. Хотя мы не верим, что долгосрочные данные будут затронуты, мы чувствовали, что вы должны знать. Ниже мы углубимся в подробности, пытаясь объяснить, что произошло в 3-м квартале и что, по нашему мнению, все это значит.

Что такое неисправность диска?
На протяжении многих лет мы заявляли, что сбой диска происходит, когда диск перестает вращаться, не остается участником RAID-массива или демонстрирует постоянное ухудшение со временем, о чем свидетельствует статистика SMART и другие системные проверки. Например, диск, который сообщает о быстро увеличивающемся или вопиющем количестве ошибок чтения носителя, является кандидатом на замену в качестве неисправного диска. Эти типы ошибок обычно видны в статистике SMART, которую мы записываем как ненулевые значения для SMART 197 и 198, которые регистрируют обнаружение и исправление поврежденных секторов диска, как правило, из-за ошибок носителя. Мы также отслеживаем другие статистические данные SMART, но эти два наиболее важны для этого обсуждения.

Что может быть неочевидным, так это то, что изменения некоторых атрибутов SMART происходят только при выполнении определенных действий. Снова используя SMART 197 и 198 в качестве примеров, на эти значения влияют только тогда, когда операция чтения или записи происходит в секторе диска, носитель которого поврежден или иным образом не позволяет выполнить операцию. Короче говоря, статистические данные SMART 197 и 198, имеющие сегодня нулевое значение, не изменятся, если во время нормальной работы диска не будет обнаружен плохой сектор. Эти две SMART-статистики не вызывают чтения и записи, они только регистрируют аномальное поведение от этих операций.

Защита сохраненных данных
Когда файл или группа файлов поступает в центр обработки данных Backblaze, файл делится на части, которые мы называем осколками. Для получения дополнительной информации о том, как создаются и используются сегменты в архитектуре Backblaze, обратитесь к сообщениям в блогах Backblaze Vault и Backblaze Erasure Coding. Для простоты, скажем, осколок — это блок данных, который находится на диске в нашей системе.

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

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

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

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

Обратите внимание на несколько моментов, поскольку мы учитываем влияние ускоренных проверок целостности осколков на данные Q3 для Drive Stats:

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

Срок службы жесткого диска Статистика до Q3 2019
Ниже приведены показатели отказов по сроку службы для всех моделей наших приводов, находящихся в эксплуатации по состоянию на 30 сентября 2019 года.


Срок службы отказов для моделей накопителей в производстве незначительно вырос с 1,70% в конце второго квартала до 1,73% в конце третьего квартала. Это тривиальное увеличение, по-видимому, указывает на то, что отмеченная выше потенциальная проблема с данными Q3 минимальна и находится в пределах нормального отклонения. Тем не менее, мы не удовлетворены тем, что это правда, и у нас есть план, чтобы убедиться, как мы увидим в следующем разделе.

Что дальше для Drive Stats?
Мы будем продолжать публиковать нашу статистику по жестким дискам каждый квартал, и в следующем квартале мы также планируем включить квартальный график (Q4). В обозримом будущем нам предстоит немного проделать внутреннюю работу, поскольку мы будем отслеживать две разные группы накопителей. Одной из групп будут диски, которые, так сказать, «прошли через червоточину», поскольку они присутствовали во время ускоренных проверок целостности осколка. Другая группа будет теми дисками, которые были запущены в производство после того, как настройка проверки целостности осколка была уменьшена. Мы сравним эти два набора данных, чтобы увидеть, действительно ли какое-либо влияние увеличенных проверок целостности осколков на частоту отказов жесткого диска Q3. Мы сообщим вам, что мы найдем в последующих отчетах по статистике дисков.

Данные о жестком диске
Полный набор данных, использованный для создания информации, использованной в этом обзоре, доступен на нашей веб-странице с данными испытаний жесткого диска. Вы можете скачать и использовать эти данные бесплатно в своих целях. Все, что мы просим, ​​- это три вещи: 1) вы цитируете Backblaze в качестве источника, если вы используете данные, 2) вы соглашаетесь с тем, что несете единоличную ответственность за то, как вы используете данные, и 3) вы не продаете эти данные кому-либо; это свободно. Удачи и дайте нам знать, что вы найдете.

Анонс Backblaze Cloud Backup 7.0: история версий и новые версии!
В этом выпуске для потребителей и предприятий добавлено одно из самых востребованных улучшений для нашей службы Backblaze Cloud Backup: возможность постоянно обновлять, изменять и даже удалять файлы в резервных копиях навсегда, расширяя историю версий. Кроме того, мы сделали наши приложения для Windows и Mac еще лучше, обновили нашу поддержку единого входа (SSO), добавили дополнительные параметры безопасности учетной записи, стали готовыми для Catalina и расширили функциональность наших мобильных приложений для iOS и Android. Эти изменения потрясающие, и мы уверены, что вы их полюбите!

Расширенная версия истории
Вы когда-нибудь удаляли файл по ошибке или случайно сохранили из-за важной работы? Backblaze всегда хранит 30-дневную историю версий ваших резервных копий, чтобы помочь в подобных ситуациях, но сегодня мы даем вам возможность продлить историю версий до одного года или навсегда. Эта новая функция доступна на странице обзора для резервного копирования компьютера и на странице управления группами, если вы используете Backblaze Groups! Backblaze v7.0 требуется для использования истории версий. Узнайте больше о версиях и расширении истории версий.


30-дневная история версий
Все учетные записи резервного копирования компьютера Backblaze имеют 30-дневную историю версий, включенную в их резервную копию. Это означает, что вы можете вернуться на 30 дней назад и восстановить старые версии ваших файлов или даже удаленных файлов.

1-летняя история версий
Продление истории версий с 30 дней до одного года означает, что все версии ваших файлов, для которых выполняется резервное копирование — независимо от того, были ли вы обновлены, изменены или полностью удалены с вашего компьютера — останутся в резервной копии Backblaze в течение одного года после изменения или удален с вашего устройства. Продление истории версий до одного года — это дополнительные 2 доллара в месяц, и плата взимается в зависимости от типа вашей лицензии (ежемесячная, годовая или 2-летняя). Как всегда, любые расходы будут пропорционально сопоставлены с датой продления лицензии.

История версий навсегда
Продление истории версий с 30 дней или одного года до бесконечности означает, что Backblaze никогда не удалит файлы из резервной копии Backblaze, независимо от того, обновили ли вы их, изменили или полностью удалили их со своего компьютера или нет. Продление истории версий навсегда аналогично одному году, за дополнительную плату в 2 доллара США в месяц (пропорционально типу вашего лицензионного плана) плюс 0,005 доллара США / ГБ в месяц за версии, измененные на вашем компьютере более года назад.



Это отличная новая функция для людей, которые хотят больше спокойствия. Чтобы узнать больше об истории версий, ценах и примерах восстановления, посетите FAQ по истории версий.
help.backblaze.com/hc/en-us/articles/360035247494

Обновления приложений MacOS и Windows
Более эффективная производительность для загрузки
Мы изменили способ, которым Backblaze передает большие файлы на ваш компьютер, переработав способ группировки и разделения файлов для загрузки. Максимальный размер пакета увеличен с 30 МБ до 100 МБ. Это позволяет приложению более эффективно передавать данные за счет лучшего использования потоков, что также сглаживает производительность загрузки, снижает чувствительность к задержкам и приводит к уменьшению структуры данных.

Обновления единого входа для групп Backblaze
Мы добавили поддержку Microsoft Office 365 в Backblaze Groups и сделали SSO-обновления для функции Inherit Backup State, чтобы она поддерживала учетные записи с поддержкой SSO. Это означает, что теперь вы можете войти в Backblaze, используя свои учетные данные Office 365, аналогично использованию единого входа Google.

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

Только для Windows
Проблема OpenSSL вызывала проблемы на чипсете Intel Apollo Lake, но мы разработали обходной путь. Apollo Lake — это чипсет более низкого уровня, поэтому не многие клиенты сталкивались с проблемами, но теперь компьютеры, использующие Apollo Lake, будут работать как положено.

Только MacOS
Мы добавили поддержку MacOS Catalina и улучшили некоторые системные сообщения MacOS. MacOS предоставляет несколько замечательных новых функций для Mac, и мы изменили некоторые из поведений нашего приложения, чтобы лучше соответствовать Catalina. В Каталине Apple теперь требует, чтобы приложения чаще запрашивали разрешение, а поскольку Backblaze является приложением для резервного копирования, нам требуется много разрешений. Таким образом, вы можете заметить больше системных сообщений при установке Backblaze на новую ОС.

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



Backblaze 7.0 Доступно: 8 октября 2019
Мы будем постепенно автоматически обновлять всех пользователей в ближайшие недели. Чтобы обновить сейчас:
Выполните проверку обновлений (щелкните правой кнопкой мыши значок Backblaze)
Скачать с www.backblaze.com/update.htm
Эта версия теперь является загрузкой по умолчанию на сайте www.backblaze.com

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

Прошло 10 лет с тех пор, как Backblaze представила миру наш накопитель. В сентябре 2009 года мы объявили о своем огромном, привлекательном красном сервере хранения 4U, оборудованном 45 жесткими дисками, обеспечивающими 67 терабайт хранилища всего за 7 867 долларов, что составляет около 0,11 доллара за гигабайт. В рамках этого объявления мы разработали дизайн для того, что мы назвали Storage Pod, и рассказали вам и всем, как вы, о том, как его создать, и многие из вас сделали.

Версия Backblaze Storage Pod 1 была анонсирована в нашем блоге с небольшой помпой. Мы подумали, что это будет интересно горстке людей — таких как ты. На самом деле, он даже не назывался версией 1, так как никто никогда не думал, что будет версия 2, а тем более версия 3, 4, 4.5, 5 или 6. Мы ошиблись. Модуль Backblaze Storage Pod покорил многих ИТ-специалистов и специалистов по хранению данных, которые были оскорблены необходимостью заплатить королевский выкуп за систему хранения высокой плотности. «Я могу построить это за десятую часть цены», — почти слышно, как они бормочут себе под нос. Бормоча или нет, мы думали то же самое, и версия 1 родилась.

Podfather
Тим, «Подфазер», как мы его знаем, был лидером Backblaze в создании первого хранилища. Он получил помощь в разработке от наших друзей из Protocase, которые создали первые три поколения модулей хранения для Backblaze, а также создали компанию под названием 45 Drives для продажи своих собственных версий модулей хранения — это открытый исходный код в лучшем виде. Прежде чем мы определились с дизайном версии 1, было несколько экспериментов:


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

Octopod был быстрым и грязным ответом на неправильные кабели SATA — слишком длинные и светящиеся. Да, в нижней части стручка просверлены отверстия.


Оригинальная лицевая панель, показанная выше, использовалась на 10 бочках для хранения до 1.0. Он был обновлен до трех кругового дизайна непосредственно перед Storage Pod 1.0.

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

Еще в 2007 году, когда мы запустили Backblaze, не было большого количества доступных вариантов для хранения больших объемов данных. Нашей целью было взимать $ 5 / месяц за неограниченное хранение данных на одном компьютере. Мы решили создать наши собственные серверы хранения, когда стало очевидно, что, если бы нам пришлось использовать другие доступные решения, нам пришлось бы брать гораздо больше денег. Storage Pod 1.0 позволил нам хранить один петабайт данных примерно за 81 000 долларов. Сегодня мы снизили это до 35 000 долларов с помощью Storage Pod 6.0. Если принять во внимание, что средний объем данных на пользователя почти утроился за тот же период времени, и наша цена теперь составляет $ 6 / месяц за неограниченное хранилище, математика сегодня работает примерно так же, как и в 2009 году.

Мы должны были сделать что-то правильно
Модуль Backblaze Storage Pod — это больше, чем просто доступное хранилище данных. Версия 1.0 представила или популяризировала три фундаментальных изменения в дизайне хранилища: 1) Вы могли бы построить систему из обычных компонентов, и она работала бы, 2) Вы могли бы монтировать жесткие диски вертикально, и они все еще вращались бы, и 3) Вы могли бы использовать жесткий потребитель диски в системе. Трудно определить, какая из этих трех функций обидела и / или взволновала больше людей. Справедливо сказать, что через десять лет все пошло нам на пользу, поскольку в настоящее время у нас на платформе имеется около 900 петабайт хранилища.

За последние 10 лет люди подогрели наш дизайн или хотя бы элементы дизайна. Начиная с 45 накопителей, многие компании работали над созданием систем хранения высокой плотности, от 45 до 102 жестких дисков в корпусе 4U, и представили различные конструкции, поэтому сегодня список систем хранения высокой плотности, в которых используются вертикально установленные накопители, впечатляет:


Другой движущей силой в разработке некоторых из этих систем является Open Compute Project (OCP). Созданные в 2011 году, они собирают и обмениваются идеями и проектами для хранения данных, конструкций стоек и связанных с ними технологий. Группой управляет The Open Compute Project Foundation как 501 © (6), и в ее состав входят многие светилы отрасли в сфере хранения данных.

Что мы сделали в последнее время?
В технологической стране 10 лет чего-либо — это много. То, что было захватывающим тогда, ожидается сейчас. И то же самое произошло с нашим любимым хранилищем. В течение многих лет мы вводили обновления и обновления, скручивая обычные циферблаты: снижение стоимости, ускорение, увеличение емкости, снижение вибрации и так далее. Все хорошее. Но мы не можем обмануть вас, особенно если вы читали это далеко. Вы знаете, что Storage Pod 6.0 был представлен в апреле 2016 года, и, откровенно говоря, это были сверчки с тех пор, как он относится к Storage Pod.

Три с лишним года без инноваций. Почему?

1. Если это не сломано, не исправляйте это. Storage Pod 6.0 построен в США компанией Equus Compute Solutions, нашим контрактным производителем, и он отлично работает. Затраты на производство понятны, производительность хороша, а новые диски более высокой плотности работают достаточно хорошо в корпусе 6.0.
2. Дисковые миграции заставляли нас быть занятыми. Со второго квартала 2016 года по второй квартал 2019 года мы перенесли более 53 000 дисков. Мы заменили диски емкостью 2, 3 и 4 терабайта на диски емкостью 8, 10 и 12 терабайт, удвоив, утроив и иногда увеличивая в четыре раза плотность хранения модуля хранения.
3. Модернизация стручка заставляла нас быть занятыми. Со второго квартала 2016 года по первый квартал 2019 года мы обновили наши старые модули хранения V2, V3 и V4.5 до V6.0. Затем мы раздавили несколько старых с помощью MegaBot и отдали больше. Сегодня уже нет автономных контейнеров для хранения; все они являются членами Хранилища Backblaze.
4. Много данных занимало нас. Во втором квартале 2016 года у нас было 250 петабайт хранения данных в производстве. Сегодня у нас есть 900 петабайт. Это много данных, которые вы, ребята, дали нам (спасибо, кстати), и множество новых систем для развертывания. На приведенной ниже диаграмме показана проблема, с которой столкнулись наши специалисты ЦОД.

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

Storage Pod Version 7.0 — Почти
Да, на чертежной доске есть Backblaze Storage Pod 7.0. Вот краткий список некоторых функций, которые мы рассматриваем:

• Обновление материнской платы
• Обновите процессор и рассмотрите возможность использования процессора AMD
• Обновление блоков питания, возможно, переход на один блок
• Обновление с 10Gbase-T до 10GbE SFP + оптическая сеть
• Обновление карт SATA
• Изменение конструкции крышки без инструментов

Сроки еще не определены, но самое подходящее время, чтобы спросить нас об этом, — начало 2020 года.

«Это хорошо», — говорите вы вслух, но на самом деле вы думаете: «Это так? Где Backblaze во всем этом? »И вот где вы входите.

Блок хранения Backblaze следующего поколения
Мы не из идей, но одна из вещей, которые мы поняли за эти годы, — то, что многие из вас действительно умны. С момента открытия проекта Storage Pod в 2009 году мы получили бесчисленное множество интересных, продуманных и иногда странных идей по улучшению дизайна. Когда мы смотрим в будущее, мы были бы глупы не спрашивать ваши мысли. Кроме того, вы все равно сообщите нам об этом в Reddit, HackerNews или о том, где вы читаете этот пост, так что давайте просто перейдем к поиску.

Построить или купить
Два основных варианта: мы проектируем и создаем свои собственные серверы хранения или покупаем их у кого-то другого. Вот некоторые из критериев, как мы думаем об этом:

• Стоимость. Нам хотелось бы, чтобы стоимость сервера хранения составляла около 0,030–0,035 долл. На гигабайт хранилища (или меньше, конечно). Это включает в себя сервер и диски внутри. Например, использование готовых жестких дисков Seagate объемом 12 ТБ (модель: ST12000NM0007) в модуле хранения 6.0 стоит около 0,032–0,034 долл. / Гигабайт в зависимости от цены накопителей в данный день.
• Международный: Теперь, когда у нас есть дата-центр в Амстердаме, мы должны иметь возможность доставлять эти серверы куда угодно.
• Техническое обслуживание: все должно быть легко починить или заменить, особенно приводы.
• Товарные части: везде, где это возможно, запчасти должны легко приобретаться, в идеале у нескольких поставщиков.
• Стойки: Мы бы предпочли продолжать использовать 42-дюймовые шкафы, но придумали что-то более глубокое и рассмотрим это.
• Возможно сегодня: нет ДНК-накопителей или других задумчивых технологий. Нам нужно хранить данные сегодня, а не в 2061 году.
• Масштабирование. Ничто в решении не должно ограничивать возможности масштабирования систем. Например, мы должны быть в состоянии обновить диски до более высокой плотности в течение следующих 5-7 лет.

Кроме этого нет никаких ограничений. Любые из следующих аббревиатур, слов и фраз могут быть частью предложенного вами решения, и мы не будем обижаться: SAS, JBOD, IOPS, SSD, резервирование, вычислительный узел, шасси 2U, шасси 3U, горизонтальные жесткие диски, прямой провод, уровни кэширования, устройство, пограничные устройства хранения, PCIe, оптоволоконный канал, SDS и т. д.

Решение не обязательно должно быть Backblaze. Как видно из списка, приведенного ранее в этом посте, Dell, HP и многие другие делают платформы хранения высокой плотности, которые мы могли бы использовать. Сделайте хороший пример для любого из этих подразделений, или любого другого, который вам нравится, и мы рассмотрим.

Что мы будем делать со всем вашим вкладом?
Мы уже начали с запуска Backblaze Labs и провели несколько экспериментов. В ближайшие месяцы мы поделимся с вами тем, что происходит, по мере продвижения этого проекта. Может быть, мы представим Storage Pod X или возьмем некоторые из подделок Storage Pod за спин. В любом случае, мы будем держать вас в курсе. Заранее благодарим за ваши идеи и спасибо за вашу поддержку в течение последних десяти лет.

www.backblaze.com

Неделя Европы в Backblaze! Во вторник мы объявили об открытии нашего первого европейского дата-центра. Вчера мы обсуждали процесс поиска источников данных. Сегодня мы сосредоточимся на том, как мы сузили список до небольшой группы финалистов. А завтра мы поделимся тем, как мы в конечном итоге выбрали нашего нового партнера.

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

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

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

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

По дороге
23 июля 2018 года Джон покинул международный аэропорт Сан-Франциско (SFO) в 7:40 утра по безостановочному маршруту в Амстердам. Принимая во внимание 5448 миль между двумя городами и изменение времени, Джон приземлился в Амстердамском аэропорту Схипхол (AMS) в 7:35 утра 24 июля. Он приземлится домой 27 июля в 6:45 вечера.

Вторник (день первый)
Первый день официально начался, когда в 7:35 утра по местному времени в Амстердаме приземлился перевод Джона в Амстердам. К счастью, перелет Криса из нью-йоркской La Guardia также был вовремя. Благодаря обоим полетам вовремя они смогли встретиться в аэропорту: буквально, потому что никогда раньше не встречались.

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

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

В первый день наша команда увидела широкий спектр вариантов. Физическое растение само по себе является одной из областей дифференциации. Несмотря на то, что у нас есть требования к таким параметрам, как мощность, пропускная способность и безопасность, все еще остается много возможностей для компромиссов между теми DC, которые превышают это требование. И это только физическое пространство. Первый этап успешного скрининга (обсуждаемый в нашем предыдущем посте) — это эффективная проверка неэмоциональных переменных решения — спецификации, цены, репутации — но не людей. Каждый ДЦ укомплектован людьми, и культурные связи важны для любого партнерства. В течение дня одним из самых больших отличий, которое мы заметили, была культура каждого конкретного ДК.

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

Покинув последний тур DC около 19:00, наша команда поехала из Амстердама в Брюссель. Второй день станет еще одним утренним стартом, и после прибытия в Брюссель чуть позже 9 вечера они заработали немного отдыха!

Совет посвященного лица: Гран-Плас, Брюссель В начале своей карьеры Джон провел много времени в Европе и, в частности, в Брюсселе. Одним из его любимых мест является Grand Place (Центральный рынок Брюсселя). Если вы по соседству, он рекомендует вам пойти и насладиться бельгийским пивом, сидя в одном из ресторанов на рынке. Умный ход — принять совет. Крис, новичок в Брюсселе, дал туру Джона благоприятный рейтинг TripAdvisor.

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

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

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

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

Четверг (день третий)
День снова начался с отъезда в 8:30 утра. Имейте в виду, что во время всего этого у Джона и Криса была своя дневная работа, и семьи возвращались домой, чтобы оставаться на связи. Сегодня будет четыре тура DC. Одно интересное замечание о поездке: для эксплуатации центра обработки данных требуется достаточное количество инфраструктуры. В идеальном мире мощность и пропускная способность поступают в разных местах от разных поставщиков. Это часто приводит к тому, что контроллеры домена объединяются вокруг узлов инфраструктуры. Первые два сегодняшних ДК были через дорогу друг от друга. Мы предполагаем, но не можем проверить, жесткое соперничество между компаниями по футболу.

Хотя прогулка по улице была интересной, в случае двух последних ДК они буквально делили одно и то же пространство; меньший провайдер субарендует пространство от большего. Здесь, опять же, действующие лица дифференцировали компании. Не обязательно, чтобы одно было хуже другого, вопрос в том, кого вы считаете лучшим партнерским партнером для вашего собственного стиля. В этом случае меньший из двух провайдеров выделялся из-за страсти и энтузиазма, которые мы испытывали от команды, и не повредило, что они давние энтузиасты Hard Drive Stats (лесть поможет вам везде!).

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

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




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

После долгой продуктивной поездки у нас был список трех финалистов. Завтра мы обсудим, как мы сократили его с трех до одного. До тех пор, убей (ура)!

На 30 июня 2019 года у Backblaze было 110 640 вращающихся жестких дисков в нашей постоянно расширяющейся экосистеме облачных хранилищ. Из этого числа было 1 980 загрузочных дисков и 108 660 дисков с данными. В этом обзоре рассматриваются Q2 2019 и коэффициенты отказов жестких дисков в течение срока службы моделей накопителей данных, которые в настоящее время используются в наших центрах обработки данных. Мы также попрощаемся с несколькими моделями накопителей, которые существуют уже несколько лет, посмотрим, как работают наши накопители Toshiba емкостью 14 ТБ (предупреждение о спойлере: отлично), и по пути мы предоставим несколько идеи и наблюдения внутри нашего хранилища. Как всегда, мы опубликуем данные, которые мы используем в этих отчетах, на нашей веб-странице с данными о тестировании жесткого диска, и мы с нетерпением ждем ваших комментариев.

Статистика отказов жесткого диска за Q2 2019
В конце второго квартала 2019 года Backblaze использовала 108 660 жестких дисков для хранения данных. Для нашей оценки мы исключаем из рассмотрения те диски, которые использовались в целях тестирования, и модели, для которых у нас не было как минимум 60 дисков (см. Почему ниже). Это оставляет нам 108 461 жестких дисков. В таблице ниже показано, что произошло во втором квартале 2019 года.


Примечания и наблюдения
Если в модели накопителя частота отказов составляет 0 процентов, это означает, что в течение второго квартала 2019 г. отказы накопителей этой модели отсутствовали — показатели отказов на весь срок службы приведены ниже в этом отчете. Два диска, перечисленные с нулевым количеством сбоев во втором квартале, были моделями Toshiba на 4 ТБ и 14 ТБ. В накопителе Toshiba 4 ТБ недостаточно большого количества накопителей или дней, чтобы быть статистически надежным, но за последние три года вышел из строя только один накопитель этой модели. Мы рассмотрим статистику накопителей Toshiba на 14 ТБ чуть позже в отчете.

Было 199 дисков (108 660 минус 108 461), которые не были включены в приведенный выше список, потому что они использовались в качестве тестовых дисков, или у нас не было по крайней мере 60 из данной модели дисков. Теперь мы используем 60 накопителей той же модели, что и минимальное количество, когда мы публикуем статистику накопителей за квартал, год и за весь срок службы, поскольку во всех вновь развернутых накопительных блоках имеется 60 накопителей — в старых моделях накопительных накопителей было минимум 45.

2000 стручков для хранения Backblaze?
В настоящее время у нас работает 1 980 накопительных контейнеров. Все они являются версией 5 или версией 6, поскольку недавно мы раздавали почти все более старые стручки для хранения людям, которые остановились у нашего хранилища в Сакраменто. Почти все, как у нас есть пара в нашем музее хранения Pod. В настоящее время существует 544 модуля версии 5, каждый из которых содержит 45 дисков данных, и существует 1436 модулей версии 6, каждый из которых содержит 60 дисков данных. В следующий раз, когда мы добавим Backblaze Vault, который состоит из 20 модулей хранения, у нас будет 2000 работающих модулей хранения Backblaze.

До свидания Western Digital
Во втором квартале 2019 года последний из накопителей Western Digital объемом 6 ТБ был снят с эксплуатации. Средний возраст дисков составлял 50 месяцев. Это были последние из наших дисков данных под маркой Western Digital. Когда Backblaze только начинался, первыми дисками данных, которые мы развернули в массовом порядке, были диски Western Digital Green 1 ТБ. Так что, с некоторой грустью, мы видим, что количество накопителей данных Western Digital обнуляется. Мы надеемся увидеть их снова в будущем.

WD Ultrastar 14 ТБ DC HC530


Привет Western Digital
Несмотря на то, что бренд Western Digital исчез, бренд HGST (принадлежащий Western Digital) становится все более сильным, поскольку у нас еще есть много фирменных накопителей HGST, около 20 процентов нашей фермы, размером от 4 до 12 ТБ. Фактически, в этом квартале мы добавили более 4700 HGST 12 ТБ накопителей.

Это только в; Ходят слухи, что двадцать один накопитель Western Digital Ultrastar по 14 ТБ готовятся к развертыванию и тестированию в одном из наших центров обработки данных. Похоже, Western Digital вернулся: следите за обновлениями.

Прощай, 5 ТБ дисков
Еще в первом квартале 2015 года мы развернули 45 накопителей Toshiba объемом 5 ТБ. Они были единственными накопителями на 5 ТБ, которые мы развернули, поскольку производители быстро перешли на диски большей емкости, и мы тоже. Тем не менее, в течение четырех с лишним лет развертывания отказали только два, без сбоев со второго квартала 2016 года — три года назад. Это затрудняло прощание, но покупка, хранение и отслеживание пары запасных дисков емкостью 5 ТБ не были оптимальными, тем более что эти запчасти нельзя было использовать где-либо еще. Так что да, диски Toshiba объемом 5 ТБ были странными утками на нашей ферме, но они были настолько хороши, что смогли остаться на четыре года.

Привет снова Toshiba 14 ТБ Диски Toshiba
Мы упоминали диски Toshiba 14 ТБ в предыдущих отчетах, и теперь мы можем углубиться в них, учитывая, что они были развернуты почти девять месяцев, и у нас есть некоторый опыт работы с ними. Эти накопители начали своеобразное начало: шесть неудач за первые три месяца использования. С тех пор произошел только один дополнительный сбой, о котором во втором квартале 2019 года не было зарегистрировано ни одного сбоя. В результате годовая частота отказов в течение срока службы накопителей Toshiba 14 ТБ снизилась до весьма приемлемых 0,78%, как показано в таблице времени жизни в следующий раздел.

Статистика срока службы жесткого диска
В приведенной ниже таблице показана частота отказов в течение срока службы моделей жестких дисков, которые мы эксплуатировали по состоянию на 30 июня 2019 года. Это за период, начинающийся в апреле 2013 года и заканчивающийся 30 июня 2019 года.


Данные о жестком диске
Полный набор данных, использованный для создания информации, использованной в этом обзоре, доступен на нашей веб-странице с данными испытаний жесткого диска. Вы можете скачать и использовать эти данные бесплатно в своих целях. Все, что мы просим, — это три вещи: 1) вы цитируете Backblaze в качестве источника, если вы используете данные, 2) вы соглашаетесь с тем, что несете единоличную ответственность за то, как вы используете данные, и 3) вы не продаете эти данные кому-либо; это свободно. Удачи и дайте нам знать, если найдете что-нибудь интересное.

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

Внедряя B2 Cloud Storage почти четыре года назад, мы были заняты добавлением улучшений и новых функций в сервис. Мы постоянно ищем способы сделать В2 более полезным для наших клиентов, будь то за счет повышения уровня обслуживания, партнерских отношений с ведущими поставщиками вычислений или снижения самой низкой в ​​отрасли цены на скачивание до 1 GB / ГБ. Сегодня мы рады объявить о выпуске бета-версии нашей новейшей функциональности: Копировать файл.
www.backblaze.com/b2/cloud-storage.html
www.backblaze.com/b2/solutions/compute.html
www.backblaze.com/b2/docs/b2_copy_file.html

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

Это была одна из наших самых востребованных функций, поскольку она разблокирует:

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

Где узнать больше о B2 Copy File
Документацию по конечной точке можно найти здесь:
b2_copy_file: www.backblaze.com/b2/docs/b2_copy_file.html
b2_copy_part: www.backblaze.com/b2/docs/b2_copy_part.html

Подробнее о бета-программе
Мы представляем эти конечные точки в виде бета-версии, чтобы разработчики могли предоставить нам обратную связь до того, как конечные точки будут запущены в производство. В частности, это означает, что API могут развиваться в результате обратной связи, которую мы получаем. Мы рекомендуем вам попробовать Copy File и, если у вас есть какие-либо комментарии, вы можете написать нашей бета-команде B2 по адресу b2beta@backblaze.com. Спасибо!

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

Левенс

Nodecraft.com — это многопользовательская облачная платформа, где геймеры могут арендовать и использовать наши серверы для создания и обмена уникальными многопользовательскими онлайн-серверами со своими друзьями и / или публикой. Владельцы серверов, использующие свои игровые серверы, создают резервные копии, включая файлы серверов, игровые резервные копии и другие файлы. Само собой разумеется, что надежность резервного копирования важна для владельцев серверов.

В ноябре 2018 года нам в Nodecraft стало ясно, что мы можем улучшить наши расходы, если пересмотрим нашу стратегию облачного резервного копирования. Изучив текущие предложения, мы решили перенести наши резервные копии с Amazon S3 на сервис Backblaze B2. В этой статье описывается, как наша команда подошла к этому, почему и что произошло, в частности, чтобы мы могли поделиться своим опытом.

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

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

Ценовой разрыв между двумя системами хранения объектов обусловлен альянсом Bandwidth между Backblaze и Cloudflare, группой провайдеров, которые согласились не взимать (или сильно снижать) плату за данные, оставленные в альянсе сетей («выходные» сборы). Мы в Nodecraft интенсивно используем Cloudflare, и поэтому оставалось беспокоиться только об исходящих затратах от Amazon до Cloudflare.

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

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

• Безопасность: нам нужно было переместить наши файлы и обеспечить их сохранность, избыточным способом
• Доступность: служба должна быть надежной, но и широко доступной ** (что означает, что нам нужно было «указать» на нужный файл после его перемещения в течение всего процесса перемещения всех файлов: у разных компаний разные стратегии, одна корзина, много ведер, областей, зон и т. д.)
• API: у нас есть опыт, поэтому мы не помешаны на проприетарных инструментах передачи файлов
• Скорость: нам нужно было перемещать файлы навалом, а не тормозить ограничения скорости, и
• Неправильная настройка может превратить операцию в нашу собственную DDoS.

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

Настройка: не отказывайтесь от собственных услуг и не вредите соседям
Что это означает для непрофессионала:

У нас много устройств в нашей сети, мы можем сделать это параллельно. Если мы сделаем это на полной скорости, мы сможем сделать так, чтобы наши поставщики услуг не очень-то нравились нам… может быть, мы должны сделать это не на полной скорости

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

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

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

Мы развернули каждый рабочий узел в виде контейнера Docker, распределенного по всему нашему Docker Swarm. Используя параметры в файле стека докеров, мы смогли определить, сколько рабочих на узел присоединилось к задаче. Это также гарантировало, что более дорогие регионы пропускной способности, такие как Азиатско-Тихоокеанский регион, не присоединились к рабочему пулу.

Тактический
У Nodecraft есть несколько парков серверов, охватывающих несколько центров обработки данных, и мы планировали использовать запасные ресурсы на большинстве из них для перемещения файлов резервных копий. Мы испытывали постоянный порядок доступа к нашим серверам со стороны наших пользователей в различных дата-центрах по всему миру, и мы знали, что будет доступность для наших целей перемещения файлов.

Наши цели в этой части операции также просты, но имеют больше шагов:

• Получить имя / идентификатор / URL-адрес файла для перемещения, который блокирует файл и запускает таймер сбоя
• Получить информацию о файле, включая размер
• СКАЧАТЬ: Скопировать файл на локальный узел (без ограничения доступности узла сети)
• Проверьте файл (размер, целостность ZIP, хэш)
• ЗАГРУЗИТЬ: скопировать файл в новый сервис (опять же, не влияя на узел)
• Сообщите «готово» с новой информацией о местоположении ID / URL на стратегическом уровне, который
• Снимает блокировку в веб-сервисе, отменяет таймер и помечает файл как DONE

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

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

Первоначально мы настроили скорость передачи файла DOWN, эквивалентную 3/4 от того, что мог сделать wget (1). Мы подумали: «Ох, сетевой трафик к узлу будет соответствовать этому, так что все в порядке». Это в основном верно, но только в основном. Это проблема в двух отношениях. Причиной проблем является то, что тесты изолированного узла являются просто изолированными. Когда большое количество узлов в центре обработки данных выполняет фактическую передачу рабочих файлов, возникает пропорциональное воздействие, поскольку трафик концентрируется в направлении выходных точек.

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

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

Уменьшая нашу настройку 3 / 4ths-wget (1) до 50% от того, что wget могла сделать для передачи одного файла, мы увидели, что наши узлы по-прежнему функционируют должным образом. Ваш пробег будет совершенно разным, и есть скрытые проблемы в деталях того, как ваши узлы могут или не могут быть рядом друг с другом, и их влияние на оборудование между ними и Интернетом.

Старые привычки
Возможно, это досадная деталь: основываясь на предыдущем жизненном опыте, я привел некоторые задержки. Мы написали эти инструменты на Python, с помощью оболочки оболочки Bourne для обнаружения сбоев (были), а также потому, что на нашем этапе загрузки мы пошли вразрез с нашей ДНК и использовали утилиту загрузки Backblaze. Кстати, он многопоточный и действительно быстрый. Но в сценарии оболочки оболочки, как само собой разумеющемся, в главном цикле, который впервые говорил с нашим API, я поместил оператор sleep 2. Это создает небольшую паузу «вверху» между файлами.

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

Наше первоначальное тестирование было завершено «Тактически», как и выше, для которого мы использовали тестовые файлы, и были очень осторожны при их проверке. В общем, мы были уверены, что сможем справиться с копированием файла (цикл Python) и проверкой (unzip -T) и работать с утилитой Backblaze b2 без особых проблем… но это стратегический уровень, который научил нас нескольким вещам.

Вспоминая туманное прошлое, когда «6% коллизий в сети 10-BASE-T и ее игра окончена»… да, 6%. Мы сократили количество реплик в Docker Swarm, и у нас не было никаких проблем. Хорошо. “Хорошо.” Тогда мы переместили дроссель, так сказать, к последней задержке.

Мы почти достигли самообороны DDoS.
Это было не так уж и плохо, но мы внезапно были очень, очень довольны нашей настройкой 50% -го-wget (1) и нашими 2-секундными задержками между передачами, и, самое главное, нашим переключателем уничтожения.

Анализ
TL; DR — Все прошло отлично.

Было несколько файлов, которые просто не хотелось передавать (их не было на S3, хм). Были некоторые DDoS-тревоги, которые на мгновение сработали. Было много трафика… и, затем, счет за пропускную способность.

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


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

У нас есть групповые (узловые) дисконтные соглашения о пропускной способности с нашими провайдерами.
B2 является членом Bandwidth Alliance и Cloudflare тоже
Мы обращались к нашему контенту S3 через наши (не бесплатные!) Публичные URL-адреса учетной записи Cloudflare, а не через (частные) S3 URL.
Не говоря уже о наших конфиденциальных договоренностях с нашими партнерами по обслуживанию, в целом верно и следующее: вы можете поговорить с поставщиками, а иногда и договориться о сокращениях. Кроме того, им особенно нравится, когда вы звоните им (заранее) и обсуждаете свои планы по усиленному управлению своей экипировкой. Например, при другом перемещении данных один из провайдеров дал нам способ «пометить» наш трафик определенным образом, и он будет проходить через тихую, но не часто посещаемую часть своей сети; победа победа!

Хочу больше?
Прочитайте пример использования Nodecraft в блоге Cloudflare.
Мы также выпустили наш собственный модуль JavaScript NPM B2-Cloud-Storage, который мы сейчас используем в производстве, чтобы упростить процесс загрузки.
Спасибо за ваше внимание, и удачи с вашим собственным байтовым стропом.

Грегори Р. Sudderth
Nodecraft Старший инженер DevOps
Наука сложна, синие клавиши на калькуляторах хитры, и у нас нет лет, чтобы изучать вещи, прежде чем делать их

По состоянию на 31 марта 2019 года у Backblaze было 106 238 вращающихся жестких дисков в нашей экосистеме облачных хранилищ, распределенных по трем центрам обработки данных. Из этого числа было 1913 загрузочных дисков и 104 325 дисков данных. В этом обзоре рассматриваются показатели первого квартала 2019 года и частоты отказов жестких дисков на моделях накопителей данных, которые в настоящее время используются в наших центрах обработки данных, и приводится несколько полезных идей и наблюдений. Кроме того, у нас есть несколько вопросов для размышления ближе к концу поста. Как всегда, мы с нетерпением ждем ваших комментариев.

Статистика отказов жесткого диска за первый квартал 2019 года
В конце первого квартала 2019 года Backblaze использовала 104 325 жестких дисков для хранения данных. Для нашей оценки мы исключаем из рассмотрения те диски, которые использовались в целях тестирования, и модели, для которых у нас не было как минимум 45 дисков (см. Почему ниже). Это оставляет нам 104 130 жестких дисков. В таблице ниже показано, что произошло в первом квартале 2019 года.


Таблица коэффициентов отказов жесткого диска Q1 2019

Примечания и наблюдения
Если в модели накопителя частота отказов составляет 0%, это означает, что в течение первого квартала 2019 года отказы накопителей этой модели отсутствовали. В первом квартале в списке приводов с нулевыми отказами были модели Toshiba объемом 4 ТБ и 5 ТБ. Ни один из них не имеет достаточно большого количества дней вождения, чтобы быть статистически значимым, но в случае модели объемом 5 ТБ вы должны вернуться ко второму кварталу 2016 года, чтобы найти последний сбой накопителя в этой модели.

Было 195 накопителей (104 325 минус 104 130), которые не были включены в приведенный выше список, поскольку они использовались в качестве тестируемых накопителей или у нас не было по крайней мере 45 данной модели накопителей. Мы используем 45 накопителей той же модели, что и минимальное количество, при составлении квартальной, годовой и пожизненной статистики накопителей. Использование 45 накопителей носит исторический характер, поскольку это было количество накопителей в наших оригинальных накопителях. В следующем квартале этот порог изменится; мы скоро к этому вернемся.

Годовой процент отказов (AFR) за 1 квартал составляет 1,56%. Это столь же высоко, как квартальная ставка с 4 квартала 2017 года, и это часть общей тенденции к повышению, которую мы наблюдаем в квартальных показателях отказов за последние несколько кварталов. Давайте посмотрим поближе.

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


Тенденции ежегодных годовых отказов жестких дисков по производителям

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

Изменение порога квалификации
Как сообщалось за последние несколько кварталов, мы перешли с дисков с низкой плотностью, дисков на 2, 3 и 4 ТБ на жесткие диски на 10, 12 и 14 ТБ. В то же время мы заменили наши автономные модули хранения с 45 дисками на блоки хранения с 60 дисками, расположенные в конфигурации Backblaze Vault из 20 блоков хранения на хранилище. В первом квартале последний автономный 45-дисковый накопитель был удален. Поэтому использование 45 накопителей в качестве порога для квалификации в нашем ежеквартальном отчете выглядит устаревшим. Это хорошее время, чтобы перейти к использованию Дней в качестве критериев квалификации. При рассмотрении наших данных мы решили использовать 5000 дней в качестве порога в будущем. Исключение составляют все текущие накопители, о которых мы сообщаем, такие как модель Toshiba 5 ТБ с продолжительностью около 4000 часов в квартал, которые будут по-прежнему включаться в наши отчеты о состоянии жестких дисков.

Меньше дисков = больше данных
Те из вас, кто следит за нашими ежеквартальными отчетами, возможно, заметили, что общее количество жестких дисков в обслуживании сократилось в 1 квартале на 648 дисков по сравнению с 4 кварталом 2018 года, но мы добавили почти 60 петабайт хранилища. Вы можете увидеть, что изменилось на графике ниже.


Backblaze Cloud Storage: количество накопителей и дисковое пространство в таблице Q1 2019

Статистика срока службы жесткого диска
В приведенной ниже таблице показана частота отказов в течение срока службы моделей жестких дисков, которые мы эксплуатировали по состоянию на 31 марта 2019 года. Это за период, начинающийся в апреле 2013 года и заканчивающийся 31 марта 2019 года.


Таблица показателей отказоустойчивости жесткого диска Backblaze

Прогнозы на остаток 2019 года
В 2019 году, вот несколько предположений относительно того, что может произойти в течение года. Давайте посмотрим, что вы думаете.

К концу 2019 года, что, если таковое произойдет, произойдет следующее? Дайте нам знать об этом в комментариях.

• Backblaze будет продолжать переносить диски емкостью 4 ТБ, и к концу 2019 года их будет менее 15 000: у нас сейчас около 35 000.
• Для тестирования мы установим как минимум двадцать 20 ТБ накопителей.
• Backblaze превысит 1 эксабайт (1000 петабайт) доступного облачного хранилища. В настоящее время мы имеем около 850 петабайт доступного хранилища.
• Для целей тестирования мы установим как минимум 1 накопитель на основе HAMR от Seagate и / или 1 накопитель MAMR от Western Digital.

Данные о жестком диске
Полный набор данных, использованный для создания информации, использованной в этом обзоре, доступен на нашей веб-странице с данными испытаний жесткого диска. Вы можете скачать и использовать эти данные бесплатно в своих целях. Все, о чем мы просим, ​​это три вещи: 1) Вы цитируете Backblaze в качестве источника, если вы используете данные, 2) Вы соглашаетесь с тем, что несете единоличную ответственность за то, как вы используете эти данные, и, 3) Вы не продаете эти данные кому-либо — это свободно.

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

Удачи и дайте нам знать, если найдете что-нибудь интересное.

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

Если вы не знакомы с Reddit IAmA (I Am a), это субреддит (/r/IAmA) для интерактивных интервью с вопросами и ответами. Реддиторы могут задавать темы по своему желанию, по этой причине она называется АМА, сокращенно «Спроси меня что-нибудь». Результирующая цепочка комментариев сохраняется в Reddit. Backblaze сделали наш первый AMA в 2012 году, поэтому мы подумали, что пришло время для второго.

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

Всемирный день резервного копирования начался аналогичным образом, когда пользователь Reddit потерял свой жесткий диск и пожелал, чтобы кто-то напомнил им о необходимости его резервного копирования. Небольшая группа в сообществе Reddit осознала важность резервного копирования и растущей тенденции потери данных. В целях повышения осведомленности они создали Всемирный день резервного копирования. С учетом наших целей, в сотрудничестве с World Backup Day и Reddit, Backblaze решила создать IAmA.

В 2012 году Backblaze была небольшой компанией с всего лишь 25 петабайтами данных под управлением и 15 сотрудниками. Большинство из нас участвовали в IAmA в этом году. В то время люди хотели знать о будущем Backblaze и возможности выхода нашей компании из бизнеса. Наш технический директор Брайан Уилсон ответил:

Мы никуда не денемся. Мы счастливы и прибыльны

Семь лет спустя оба эти утверждения все еще остаются в силе.
Конечно, за почти десятилетие многое изменилось. Мы храним более 750 ПБ данных клиентов от клиентов в более чем 150 странах. Наша команда из 15 человек выросла почти до 100. Но некоторые вещи остаются прежними — менее 6% владельцев компьютеров резервируют свои данные один раз в день или больше. Поэтому Backblaze решила вернуться в Reddit, чтобы рекламировать Всемирный день резервного копирования и зарегистрироваться в Интернете.

Еще раз, наиболее одобренный комментарий пришел от нашего технического директора, Брайана. Когда его спросили, почему Backblaze заставляет пользователей делать резервные копии своего диска C, Брайан объяснил, что он написал клиент так, чтобы «решить очень реальную проблему».

Эта проблема
Изначально Backblaze позволяла пользователям отменять выбор своего основного диска. И ужасная проблема появилась почти сразу. Клиенты начали отменять выбор своего диска, потому что они не знали, что диск C содержит данные, которые им могут понадобиться, или просто по ошибке. Затем они обратились бы в нашу службу поддержки и обнаружили, что не смогли восстановить свои данные. Это включало в себя фотографии детей, которые уже скончались (у нас было два случая этой точной ситуации), и другие незаменимые данные, которые теперь ушли навсегда.

Решение
В этот момент Брайан переписал клиент, чтобы принудительно включить основной диск. Это было решение, которое некоторым не нравилось. Однако, по словам Брайана, «исправление сработало потрясающе», и у нас больше нет клиентов, случайно теряющих данные, потому что они отменяют выбор своего накопителя. Основываясь на многочисленных ответах людей, работающих в IT, Брайан понял это правильно. «Программное обеспечение должно быть написано для конечного пользователя», — ответил один из ИТ-специалистов. «Все лучшее и самое популярное программное обеспечение (и оборудование) просты и легки в освоении».

Какие были еще вопросы?
В то время как мы изначально запланировали два часа для IAmA, мы закончили тем, что ушли на пять (наш социальный парень, Yev, может все еще быть там прямо сейчас).

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


Интересно было то, как Backblaze продолжает предоставлять действительно неограниченное решение для резервного копирования компьютеров. В нашей отрасли практически все безграничные решения исчезли с рынка. Но Backblaze удвоился за последние несколько лет. Это вызывает вопрос о том, как мы продолжаем устойчиво поддерживать продуктовую линейку. В настоящее время у нас есть один клиент, поддерживающий 430 терабайт за 6 долларов в месяц. По этой цене мы явно теряем деньги на этом клиенте. Тем не менее, большинство наших клиентов имеют гораздо меньше данных. Таким образом, в то время как мы теряем деньги на этом одном клиенте, мы в среднем прибыльны. Есть и другие причины для поддержки выбросов — эти клиенты демонстрируют, что мы действительно безграничны. Ни один сервис, который ограничивал или выборочно создавал резервные копии файлов, не позволил бы создать резервную копию 430 ТБ. Да, это в конечном итоге приводит к издержкам бизнеса, но эти отдаленные клиенты тоже становятся большими евангелистами. Вы не получаете столько данных, не будучи энтузиастом хранилища. Наш технический директор, Брайан, выдвинул еще одну вескую причину: когда продукт работает на действительно большие выбросы, тогда «он будет работать очень гладко для среднего клиента».

Если вы хотите больше узнать о нашей беседе с IAmA, вы можете сделать это на Reddit. Или, если вы хотите сделать резервную копию всех данных ваших конечных пользователей самым простым и надежным способом, мы приглашаем вас попробовать Backblaze Business Backup.