Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 51
Только я прочел red shit?
Занятно, сколько бы стоило у себя на предприятии поднять сторедж размером в 1 петабайт сроком использования 5 лет с высокой доступностью данных, отказоустойчивостью и прочими плюшками? Само собой еще есть масса факторов которые повлияют на конечную стоимость, но почему-то мне кажеться, что стоимость решений будет сопоставима с облачным, с единственной разницей — время развертывания.
Никто никогда не занимался хранилищами такого объема? Было бы интересно услышать из первых уст.
Никто никогда не занимался хранилищами такого объема? Было бы интересно услышать из первых уст.
С доступностью, которую гарантирует амазон это будет очень дорого.
Фактически свой ДЦ построить, а желательно 2.
Фактически свой ДЦ построить, а желательно 2.
В чем разница между «гарантирует» и «обещает»? Чем он гарантирует? Может компенсацией какой то? Да нет, просто опять скажут «извините, экстраординарное происшествие, мы прикладываем все усилия что бы этого больше не произошло».
С удовольствием выслушаю ваши предложения по организации целостности объектов на 99.999999999% в год на 1 ПБ :)
А что, сервис уже год проработал? Не так давно их облако упало на весьма продолжительное время. Я вообще про то что употреблять слово «гарантирует» некорректно (я бы сказал бесчестно).
1PB это не так много сегодня. Даже, если строить это на обычных серверах. если брать 36 дисков по 4Тб, поставить raid6 и один hot-spare, то выйдет 120Тб с сервера с надежностью 99.99% (если разместить в нормальной гермозоне).
Итого, 8 серверов, 15k$ на сервер = 120k$. Для повышения сохранности данных, вторую копию серверов ставим в ДЦ за, скажем, 2000$ в месяц. Получаем надежность сохранности не хуже Амазоновской с очень высокой скоростью доступа (хранилище по сути, в локальной сети).
Если считать, что хостинг в офисе обойдется еще 1000$ в месяц, то получаем стоимость решения 7К$ в месяц.
Решение от Гугла обойдется чуть меньше 50k$, от Амазона еще дороже. Даже если добавить 500$ в месяц на амортизацию оборудования и часть ЗП человека, что будет менять винты и пару тысяч на первоначальную настройку, все равно выйдет существенно быстрее и дешевле. Не просто существенно, а почти на порядок.
Итого, 8 серверов, 15k$ на сервер = 120k$. Для повышения сохранности данных, вторую копию серверов ставим в ДЦ за, скажем, 2000$ в месяц. Получаем надежность сохранности не хуже Амазоновской с очень высокой скоростью доступа (хранилище по сути, в локальной сети).
Если считать, что хостинг в офисе обойдется еще 1000$ в месяц, то получаем стоимость решения 7К$ в месяц.
Решение от Гугла обойдется чуть меньше 50k$, от Амазона еще дороже. Даже если добавить 500$ в месяц на амортизацию оборудования и часть ЗП человека, что будет менять винты и пару тысяч на первоначальную настройку, все равно выйдет существенно быстрее и дешевле. Не просто существенно, а почти на порядок.
1) Вы не учли стоимость трафика по каналу 10Gbps
2) 2k$/mo за 8 серверов — это по 250$/сервер — мне кажется это слишком мало — т.к. трафик будет стоить дороже
3) по Вашим расчетам 36 (дисков) * 4 (ТБ) * 8 (серверов) — НО это ведь не HA — поэтому нужно все цифры умножить на 2 — чтобы получился аналог RAID1 через сеть
4) хостинг в офисе — тут вообще странно, зачем?
2) 2k$/mo за 8 серверов — это по 250$/сервер — мне кажется это слишком мало — т.к. трафик будет стоить дороже
3) по Вашим расчетам 36 (дисков) * 4 (ТБ) * 8 (серверов) — НО это ведь не HA — поэтому нужно все цифры умножить на 2 — чтобы получился аналог RAID1 через сеть
4) хостинг в офисе — тут вообще странно, зачем?
А какая стоимость трафика?=) В локалке на равна 0 (ну только амортизация железа, сейчас уже недорогого), а между локальным хранилищем и ДЦ вполне хватит гигабита, достаточно недорогого, если в ДЦ ходить через точку обмена в том-же городе.
2К это стоимость стойки, sla и гигабитного канала до точки обмена. Вполне адекватно.
Я умножил на 2, читайте внимательно.
хостинг в офисе, чтобы огранизовать доступ на скорости 10-20-30Г (сколько нужно). У Амазона может и есть такие каналы, но стоит такой линк из офиса до амазона будет очень дорого. Если данные доступают не из офиса, тогда берем 2ДЦ и +1К$ к помесячной плате.
2К это стоимость стойки, sla и гигабитного канала до точки обмена. Вполне адекватно.
Я умножил на 2, читайте внимательно.
хостинг в офисе, чтобы огранизовать доступ на скорости 10-20-30Г (сколько нужно). У Амазона может и есть такие каналы, но стоит такой линк из офиса до амазона будет очень дорого. Если данные доступают не из офиса, тогда берем 2ДЦ и +1К$ к помесячной плате.
Смотря, с какой скоростью будете наполнять. Допустим, если речь о рекламном агентстве, что хранит оригиналы отснятого материала, то слить даже по гигабиту весь отснятый за день материал за одну ночь более, чем реально.
Если данные в хранилище поступают постоянно более, чем на гигабите в секунду, то канал, ясное дело, нужно расширять на сколько, сколько нужно. Для 99% сценариев применения такого хранилища, гигабита хватит.
Если данные в хранилище поступают постоянно более, чем на гигабите в секунду, то канал, ясное дело, нужно расширять на сколько, сколько нужно. Для 99% сценариев применения такого хранилища, гигабита хватит.
Что-то у вас с арифметикой, 1 петабайт = 1000 терабайт = 1000 000 гигабайт.
1ПБ / 3.6ТБ/день = 278 дней. Вполне себе нормальная цифра.
И да, хранилища подобных масштабов редко когда наполняется внезапно, чаще всего это занимает время. Даже если видеоролики хранить в нём. Гигабит нужен для репликации, пики будут только при потере диска — надо будет из другого ДЦ перелить на него данные.
Про достаточность канала в один-два гигабита между ДЦ (если снаружи приходит меньше гигабита траффика, ессно) — это из личной практики, есличо.
1ПБ / 3.6ТБ/день = 278 дней. Вполне себе нормальная цифра.
И да, хранилища подобных масштабов редко когда наполняется внезапно, чаще всего это занимает время. Даже если видеоролики хранить в нём. Гигабит нужен для репликации, пики будут только при потере диска — надо будет из другого ДЦ перелить на него данные.
Про достаточность канала в один-два гигабита между ДЦ (если снаружи приходит меньше гигабита траффика, ессно) — это из личной практики, есличо.
С арифметикой действительно не все ок. Но вы не озвучили цели хранилища. Если вы планируете собирать данные об отдельный атомах в рамках эксперимента что длится 10 секунд и за эти секунды весь петабайт и поступит, конечно, не подойдет мое решение.
Насколько Я знаю Amazon всегда говорили — что если нужно HA то покупайте второй инстанц во другой зоне.
Поэтому по сути все эти цифры нужно увеличить минимум в 2 раза (для 2N)
Поэтому по сути все эти цифры нужно увеличить минимум в 2 раза (для 2N)
Скорее всего можно уложиться в $800К — $1М с поддержкой всего хозяйства на 5 лет (если уже есть датацентр). Я работаю с похожими системами — например, bit.ly/JWUgf2 и bit.ly/xF20xm. Там конечно 1Пб до потерь на RAID, но добавить пару JBOD'ов — не проблема. Правда, логичнее взять несколько систем поменьше — N+1 High Availability систем на 250-500Тб usable space — заодно и доступность в среднем повысится.
Если не нужно видеть все хранилище как один диск, то можно уложиться в гораздо меньшие деньги: 450K$ на все время вместе с обслуживанием и размещением резерва в ДЦ.
Для критичный данных было бы лучше сделать разделенное хранилище по типу улья с связями между ними через 40Gbps порт — внутри ДЦ самое то, также в случае отказа узла его можно будет заменить гораздо просто нежели когда все-в-одном. Ну и естественно FS выбрать типа OCFS2 или ZFS — устойчивую к потерям сегментов.
Ну я предложил вариант держать локально с небольшим резервированием и полную копию в ДЦ на всяких случай. При таком раскладе, можно как переключаться на хранилище в ДЦ при аварии локального (если канал в офисе хороший), так и просто использовать его именно как бекап, поднимать то, что отвалилось на локальном и восстанавливать из ДЦ данные.
Кстати, как один винт таки можно сделать, просто выйдет чуть меньше 1Тб (соединить 256 винтов в разных корпусах через экспандеры. Так можно вместо 8 серверов использовать один на 1-2U и корзину юнитов на 8, т.е. компактнее будет и дешевле
Кстати, как один винт таки можно сделать, просто выйдет чуть меньше 1Тб (соединить 256 винтов в разных корпусах через экспандеры. Так можно вместо 8 серверов использовать один на 1-2U и корзину юнитов на 8, т.е. компактнее будет и дешевле
Пардон, Я думал Вы хотите все расположить в ДЦ.
Оффлайн бэкапы для HA будут не совсем то — разумнее использовать непрерывное копирование, а там тогда стоимость серверов в ДЦ будет выше.
Зкспандеры это хорошо, но не будет ли все упираться в шину контроллера RAID?
P.S. разве в офисах часто бывают линии на 10/40Gbps?
Оффлайн бэкапы для HA будут не совсем то — разумнее использовать непрерывное копирование, а там тогда стоимость серверов в ДЦ будет выше.
Зкспандеры это хорошо, но не будет ли все упираться в шину контроллера RAID?
P.S. разве в офисах часто бывают линии на 10/40Gbps?
оффлайн это восстановление, бекапы непрерывные, как только файл попал на локальное хранилище, сразу пулится в ДЦ и наоборот (если нужно).
Внутри офиса можно построить и 10Г и 40Г, если нужно, порядок цен сильно меньше офисанных трат на хранилище. От ДЦ до офиса достаточно гигабита, даже шаренного (чем меньше скорость, тем выше вероятность потери последних данных. Но в целом, вероятность очень небольшая в любом случае и это все равно надежнее, чем пулинг по мировому каналу до амазона напрямую).
Шина 24Гбита минимум (x8 2.0), 96 максимум (x16 3.0). Упереться в нее сложно, скорее упретесь в сеть или винты. В прочем, с помощью небольших доработок можно и тут расшириться.
Внутри офиса можно построить и 10Г и 40Г, если нужно, порядок цен сильно меньше офисанных трат на хранилище. От ДЦ до офиса достаточно гигабита, даже шаренного (чем меньше скорость, тем выше вероятность потери последних данных. Но в целом, вероятность очень небольшая в любом случае и это все равно надежнее, чем пулинг по мировому каналу до амазона напрямую).
Шина 24Гбита минимум (x8 2.0), 96 максимум (x16 3.0). Упереться в нее сложно, скорее упретесь в сеть или винты. В прочем, с помощью небольших доработок можно и тут расшириться.
It depends. Зависит от того, насколько важен аптайм и скорость. Если не критично, то можно использовать поды типа Backblaze (135Тб за $7400) и распределенную кластерную open-source ФС, что-нибудь вроде Sheepdog, Ceph или Lustre.
Я работаю с ZFS — она отлично масштабируется, но только в пределах одной ноды, с failover cluster для HA.
Я работаю с ZFS — она отлично масштабируется, но только в пределах одной ноды, с failover cluster для HA.
Разница в цене, на сколько я понял обусловлена тем, что в ваших вариантах винты по 2ТБ, а у меня по 4, соотвественно выше плотность, меньше дополнительного обслуживающего железа (контроллеры, платформы). На надежность это не сильно влияет, и как строить на уровне софта это тоже вопрос следующий.
В одном из вариантов по 2Тб, в другом по 3. Можно и 4Тб использовать, но там с восстановлением массива после потери диска вообще беда — я бы их ставил только в striped 3-way mirror или striped Raidz3. Размер дисков всё растёт, а IOPs — нет.
Ну значит, лучше использовать мое решение выше. Если использовать отдельные сервера, на основновных кроме винтов поставить еще ssd кеш на дисков 6 по 512GB, то вполне реально снимать до 15Г c сервера (120 с 8ми серверов, но это в пике) и объединить эти сервера уже через zfs или подобное (в том числе с теми, что стоят в ДЦ), то все будет работать быстро и надежно, только ssd чтобы поменять придется сервер разобрать (но не выключать)
Думается мне, что всяко дешевле чем $1 млн в год
Судя по тому что
Durable Reduced Availability Storage больше похоже на AWS Reduced Redundancy Storage, чем на AWS Glacier (да и по цене тоже).
Durable Reduced Availability Storage enables you to store data at lower cost, with the tradeoff of lower availability than standard Google Cloud Storage.
Durable Reduced Availability Storage больше похоже на AWS Reduced Redundancy Storage, чем на AWS Glacier (да и по цене тоже).
Интересно, как они собираются гарантировать консистентность всего раздела, он ведь явно не на один сервер ляжет. Видимо, будет не особо быстро работать.
думаю будет наоборот — скорость высокой, а вот IOPS низкий.
По поводу размера они могут к серверу просто поставить дисковую полку или пробросить SAN внутри ДЦ.
По поводу размера они могут к серверу просто поставить дисковую полку или пробросить SAN внутри ДЦ.
Дисковая полка, даже набитая 4ТБ винтами — это всего 100ТБ. В 10 раз меньше. И это ещё без какого-либо резервирования. Я же говорю, 1ПБ на одном сервере не завести никак, это несколько серверов в сети. А несколько серверов — это проблемы с консистентностью, за решение которых надо платить потерей IOPS и, скорее всего, скорости.
В то, что они какой-нибудь NetApp сторадж используют — не верится.
В то, что они какой-нибудь NetApp сторадж используют — не верится.
Ну смотрите — если выделить целую стойку или несколько стоит то можно получить и 1ПБ.
Консистентность теоретически можно решить если поставить единую точку входа, но при этом правда и надежность тоже будет уменьшена.
Я тоже сомневаюсь, но IOPS точно будет низким т.к. в AWS сейчас так и есть.
Консистентность теоретически можно решить если поставить единую точку входа, но при этом правда и надежность тоже будет уменьшена.
Я тоже сомневаюсь, но IOPS точно будет низким т.к. в AWS сейчас так и есть.
Я и так знаю, как сделать S3 петабайтового размера, и сколько это будет стоить :) Но при разумном ограничении размера каждого объекта в единицы и десятки гигабайт.
А вот как хранить 1ПБ файл (типа образ диска, на котором файловая система), чтобы он был в консистентном состоянии и уметь его восстанавливать — вопрос действительно интересный, и просто набиванием дисками стойки его не решить, тут должен быть какой-то софт. Может быть, специальная файловая система. Или на самом деле хранятся куски файла, а в линкусе специальный драйвер блочных устройств, который требует от хранилища только консистентность на уровне блока. Но про это как-то не пишут :(
А вот как хранить 1ПБ файл (типа образ диска, на котором файловая система), чтобы он был в консистентном состоянии и уметь его восстанавливать — вопрос действительно интересный, и просто набиванием дисками стойки его не решить, тут должен быть какой-то софт. Может быть, специальная файловая система. Или на самом деле хранятся куски файла, а в линкусе специальный драйвер блочных устройств, который требует от хранилища только консистентность на уровне блока. Но про это как-то не пишут :(
Я же говорю, 1ПБ на одном сервере не завести никак, это несколько серверов в сети.
Запросто :) И без всяких NetApp/EMC/Hitachi. Правда будет сервер + несколько полок с дисками, но 1Пб raw в одной системе под ZFS — не проблема.
Xyratex уже делает 4U JBODы на 72 диска каждый; DataOn есть на 60 дисков в 4U. Так что с Xyratex, например, можно в 18U сделать массив с 1.15Пб; в 42U — 2.88Пб. Для data warehousing вполне подходит; для general purpose storage (DB, VM) более важны IOPs, так что там имеет смысл делать либо 10к/15к диски, либо SSD.
С Xyratex ошибся, там 84 дисков в 5U. Ну неважно.
Вот пример 1Пб системы с примерным раскладом цен на базе Illumos+ZFS (Free Open-Source) и DataOn DNS-1660 (все компоненты enterprise-class):
6x DataOn DNS-1660D: $66,000
360x Seagate Constellation ES.3 4Tb: $180,000
2x LSI SAS6160 Switch: $4,000
Head node типа Dell R720xd с 384Гб памяти, парой Xeon E5, 2x LSI 9201-16e, 2x Dual-port 10Gbe — скажем, $30,000 (лень считать).
~$4000 на всякие мелочи вроде кабелей, итд.
Если надо, добавить несколько STEC ZeusRAM для write cache; STEC Z16 для read cache, можно прямо в контроллер — от $15к и выше.
В базе получается <$300k + налоги в США.
Потом делаем 32*(11-disk raidz3) + 8 hot spare, получается 1Пб usable space, или 1.44Пб raw space.
Такие системы народ реально использует в продакшн, правда обычно делают 2 контроллера в кластере, и коммерческий софт.
Вот пример 1Пб системы с примерным раскладом цен на базе Illumos+ZFS (Free Open-Source) и DataOn DNS-1660 (все компоненты enterprise-class):
6x DataOn DNS-1660D: $66,000
360x Seagate Constellation ES.3 4Tb: $180,000
2x LSI SAS6160 Switch: $4,000
Head node типа Dell R720xd с 384Гб памяти, парой Xeon E5, 2x LSI 9201-16e, 2x Dual-port 10Gbe — скажем, $30,000 (лень считать).
~$4000 на всякие мелочи вроде кабелей, итд.
Если надо, добавить несколько STEC ZeusRAM для write cache; STEC Z16 для read cache, можно прямо в контроллер — от $15к и выше.
В базе получается <$300k + налоги в США.
Потом делаем 32*(11-disk raidz3) + 8 hot spare, получается 1Пб usable space, или 1.44Пб raw space.
Такие системы народ реально использует в продакшн, правда обычно делают 2 контроллера в кластере, и коммерческий софт.
Потом пропадает питание у ОДНОЙ полки и весь раздел разваливается. Или у вас 32 раздела получается? В каждой полке сколько дисков может вылететь, максимум один? Я уж не говорю про скорость восстановления реида под нагрузкой.
И эта схема не скейлится, 2ПБ уже не сделать никак.
Хотя я сейчас прочитал ещё раз описание сервиса на сайте амазона — тупо 24 диска предлагают, а это уже не интересно совсем.
И эта схема не скейлится, 2ПБ уже не сделать никак.
Хотя я сейчас прочитал ещё раз описание сервиса на сайте амазона — тупо 24 диска предлагают, а это уже не интересно совсем.
Потом пропадает питание у ОДНОЙ полки и весь раздел разваливается. Или у вас 32 раздела получается?
32 раздела, 11 дисков в каждом (из них 3 можно потерять без потери данных). 2 диска из одного раздела в каждой полке, так что одну можно потерять без особых проблем.
И эта схема не скейлится, 2ПБ уже не сделать никак.
Скейлится прекрасно, минимум до 11 полок (между полками и контроллером два SAS-свича). Кстати, если добить до 11-12 полок, то можно потерять и 3, но тогда совсем хреново будет. 2 — нормально. 11 полок — это 2.6Пб (1.92 usable).
Теоретически можно и больше, но практически после 1Пб usable затык будет уже в контроллере (PCIe, память), так что реально там уже надо будет scale out.
Вот система с которой работал на выходных — 14 полок, правда по 24 диска всего. 2 контроллера. 240 3Тб дисков и 120 SSD. i48.tinypic.com/2mlp3.jpg
Скейлится прекрасно, минимум до 11 полок
Ну то есть фигово скейлится :) Горизонтальное масштабирование — это когда в разы легко можно увеличить объём. Опять же, вопрос с пропаданием питания на стойке не решён, не всегда можно так делать.
Это я к тому, что вешать много полок на 1 машину — тупиковый путь, подходит только если не надо будет потом увеличивать объём.
Так я собственно и говорю, что в какой-то момент без scale out не обойтись. Вопрос в том, когда, и сколько это будет стоить с точки зрения поддержки нескольких систем против одной. Кластер для big data или image/video production (большие объемы данных под одним namespace) — имеет смысл до 1Пб на ноду (а несколько нод можно объединить через NFS Referrals). Кластер для cloud/VM/VDI — до 200Тб на ноду — одной виртуалке очень редко нужны LUNы >10Тб, а если нужны, это надо учитывать в дизайне. Есть варианты где имеет смысл делать 100+ маленьких 2U нод с 15к дисками или SSD, особенно если доступ к данным идет через умный прокси (OpenStack Swift/Nova или другие API).
Иногда делаем back-end на FC или iScsi/AoE/FCoE/IB и скейлим front-end независимо от back-end'a, таким образом обходим практические ограничения SAS полок на ноду.
Иногда делаем back-end на FC или iScsi/AoE/FCoE/IB и скейлим front-end независимо от back-end'a, таким образом обходим практические ограничения SAS полок на ноду.
Гугл сегодня снизил еще на 10%. Так можете обновить инфу в таблице.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Amazon Redshift: новое хранилище данных на петабайты