Регистрация
29 ноября 2012 в 00:55

Amazon Redshift: новое хранилище данных на петабайты

    Компания Amazon выкатила принципиально новый сервис Redshift для хранения баз данных размером от нескольких сотен гигабайт до многих петабайт. Продукт нацелен на корпоративных заказчиков, которых сдерживает ограничение в 1 терабайт традиционной RDS, при этом хотят пользоваться привычными SQL-приложениями и гарантировать мгновенную доступность данных.

    Кластер Redshift поднимается в пару щелчков мыши из административной панели AWS. Стоимость хранения данных здесь сравнима с обычным S3 и зависит от типа кластера и тарифного плана. Например, на трёхлетнем плане она составляет $999 за терабайт в год.

    Пользователям Redshift предлагается два типа серверов для кластера: XL и 8XL.

    High Storage Extra Large (XL) DW Node


    • CPU: 2 виртуальных ядра
    • ECU: 4.4
    • Память: 15 GiB
    • Диски: 3 HDD with 2 TB of local attached storage
    • Сеть: средняя
    • Скорость I/O с диском: средняя
    • API: dw.hs1.xlarge


    High Storage Eight Extra Large (8XL) DW


    • CPU: 16 virtual cores
    • ECU: 35
    • Память: 120 GiB
    • Диски: 24 HDD с 16 TB локального пространства
    • Сеть: 10 Gigabit Ethernet
    • Скорость I/O с диском: очень высокая
    • API: dw.hs1.8xlarge

    Одновременно c анонсом Redshift компания Amazon на 25% снизила цены на хостинг S3.



    В тот же день компания Google тоже снизила цены на 20% на хранение данных в Google Cloud Platform, и объявила о запуске нового сервиса по дешёвому долговременному хранению архивов Durable Reduced Availability Storage, по типу AWS Glacier.

    Теги:
    Хабы:
    Реклама
    Ой, у вас баннер убежал!

    Ну. И что?

    Похожие публикации

    Заказы

    Больше заказов на Хабр Фрилансе
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 51

      –27
      Только я прочел red shit?
        +13
        Кажется да.
          –11
          Кажется нет, иначе минусов было бы больше в разы.
            –10
            Ну и что это? Что за несколько жалких «импотентских» минусов?
        0
        Занятно, сколько бы стоило у себя на предприятии поднять сторедж размером в 1 петабайт сроком использования 5 лет с высокой доступностью данных, отказоустойчивостью и прочими плюшками? Само собой еще есть масса факторов которые повлияют на конечную стоимость, но почему-то мне кажеться, что стоимость решений будет сопоставима с облачным, с единственной разницей — время развертывания.
        Никто никогда не занимался хранилищами такого объема? Было бы интересно услышать из первых уст.
          +1
          С доступностью, которую гарантирует амазон это будет очень дорого.

          Фактически свой ДЦ построить, а желательно 2.
            +5
            В чем разница между «гарантирует» и «обещает»? Чем он гарантирует? Может компенсацией какой то? Да нет, просто опять скажут «извините, экстраординарное происшествие, мы прикладываем все усилия что бы этого больше не произошло».
              +3
              С удовольствием выслушаю ваши предложения по организации целостности объектов на 99.999999999% в год на 1 ПБ :)
                +1
                А что, сервис уже год проработал? Не так давно их облако упало на весьма продолжительное время. Я вообще про то что употреблять слово «гарантирует» некорректно (я бы сказал бесчестно).
                  –1
                  Что падало, где и насколько?
                    0
                    1PB это не так много сегодня. Даже, если строить это на обычных серверах. если брать 36 дисков по 4Тб, поставить raid6 и один hot-spare, то выйдет 120Тб с сервера с надежностью 99.99% (если разместить в нормальной гермозоне).

                    Итого, 8 серверов, 15k$ на сервер = 120k$. Для повышения сохранности данных, вторую копию серверов ставим в ДЦ за, скажем, 2000$ в месяц. Получаем надежность сохранности не хуже Амазоновской с очень высокой скоростью доступа (хранилище по сути, в локальной сети).

                    Если считать, что хостинг в офисе обойдется еще 1000$ в месяц, то получаем стоимость решения 7К$ в месяц.

                    Решение от Гугла обойдется чуть меньше 50k$, от Амазона еще дороже. Даже если добавить 500$ в месяц на амортизацию оборудования и часть ЗП человека, что будет менять винты и пару тысяч на первоначальную настройку, все равно выйдет существенно быстрее и дешевле. Не просто существенно, а почти на порядок.
                      +1
                      1) Вы не учли стоимость трафика по каналу 10Gbps
                      2) 2k$/mo за 8 серверов — это по 250$/сервер — мне кажется это слишком мало — т.к. трафик будет стоить дороже
                      3) по Вашим расчетам 36 (дисков) * 4 (ТБ) * 8 (серверов) — НО это ведь не HA — поэтому нужно все цифры умножить на 2 — чтобы получился аналог RAID1 через сеть
                      4) хостинг в офисе — тут вообще странно, зачем?
                        +1
                        А какая стоимость трафика?=) В локалке на равна 0 (ну только амортизация железа, сейчас уже недорогого), а между локальным хранилищем и ДЦ вполне хватит гигабита, достаточно недорогого, если в ДЦ ходить через точку обмена в том-же городе.

                        2К это стоимость стойки, sla и гигабитного канала до точки обмена. Вполне адекватно.

                        Я умножил на 2, читайте внимательно.

                        хостинг в офисе, чтобы огранизовать доступ на скорости 10-20-30Г (сколько нужно). У Амазона может и есть такие каналы, но стоит такой линк из офиса до амазона будет очень дорого. Если данные доступают не из офиса, тогда берем 2ДЦ и +1К$ к помесячной плате.
                        • НЛО прилетело и опубликовало эту надпись здесь
                            0
                            Смотря, с какой скоростью будете наполнять. Допустим, если речь о рекламном агентстве, что хранит оригиналы отснятого материала, то слить даже по гигабиту весь отснятый за день материал за одну ночь более, чем реально.

                            Если данные в хранилище поступают постоянно более, чем на гигабите в секунду, то канал, ясное дело, нужно расширять на сколько, сколько нужно. Для 99% сценариев применения такого хранилища, гигабита хватит.
                            • НЛО прилетело и опубликовало эту надпись здесь
                                0
                                Что-то у вас с арифметикой, 1 петабайт = 1000 терабайт = 1000 000 гигабайт.
                                1ПБ / 3.6ТБ/день = 278 дней. Вполне себе нормальная цифра.

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

                                Про достаточность канала в один-два гигабита между ДЦ (если снаружи приходит меньше гигабита траффика, ессно) — это из личной практики, есличо.
                                • НЛО прилетело и опубликовало эту надпись здесь
                                  0
                                  С арифметикой действительно не все ок. Но вы не озвучили цели хранилища. Если вы планируете собирать данные об отдельный атомах в рамках эксперимента что длится 10 секунд и за эти секунды весь петабайт и поступит, конечно, не подойдет мое решение.
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                      0
                                      Обратите пожалуйста внимание на то, где именно находится гигабитный канал и зачем он нужен. (подсказка: исключительно для инкрементного бекапа).
                      0
                      Насколько Я знаю Amazon всегда говорили — что если нужно HA то покупайте второй инстанц во другой зоне.
                      Поэтому по сути все эти цифры нужно увеличить минимум в 2 раза (для 2N)
                0
                Скорее всего можно уложиться в $800К — $1М с поддержкой всего хозяйства на 5 лет (если уже есть датацентр). Я работаю с похожими системами — например, bit.ly/JWUgf2 и bit.ly/xF20xm. Там конечно 1Пб до потерь на RAID, но добавить пару JBOD'ов — не проблема. Правда, логичнее взять несколько систем поменьше — N+1 High Availability систем на 250-500Тб usable space — заодно и доступность в среднем повысится.
                  –1
                  Если не нужно видеть все хранилище как один диск, то можно уложиться в гораздо меньшие деньги: 450K$ на все время вместе с обслуживанием и размещением резерва в ДЦ.
                    0
                    Для критичный данных было бы лучше сделать разделенное хранилище по типу улья с связями между ними через 40Gbps порт — внутри ДЦ самое то, также в случае отказа узла его можно будет заменить гораздо просто нежели когда все-в-одном. Ну и естественно FS выбрать типа OCFS2 или ZFS — устойчивую к потерям сегментов.
                      0
                      Ну я предложил вариант держать локально с небольшим резервированием и полную копию в ДЦ на всяких случай. При таком раскладе, можно как переключаться на хранилище в ДЦ при аварии локального (если канал в офисе хороший), так и просто использовать его именно как бекап, поднимать то, что отвалилось на локальном и восстанавливать из ДЦ данные.

                      Кстати, как один винт таки можно сделать, просто выйдет чуть меньше 1Тб (соединить 256 винтов в разных корпусах через экспандеры. Так можно вместо 8 серверов использовать один на 1-2U и корзину юнитов на 8, т.е. компактнее будет и дешевле
                        0
                        Пардон, Я думал Вы хотите все расположить в ДЦ.
                        Оффлайн бэкапы для HA будут не совсем то — разумнее использовать непрерывное копирование, а там тогда стоимость серверов в ДЦ будет выше.
                        Зкспандеры это хорошо, но не будет ли все упираться в шину контроллера RAID?
                        P.S. разве в офисах часто бывают линии на 10/40Gbps?
                          0
                          оффлайн это восстановление, бекапы непрерывные, как только файл попал на локальное хранилище, сразу пулится в ДЦ и наоборот (если нужно).

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

                          Шина 24Гбита минимум (x8 2.0), 96 максимум (x16 3.0). Упереться в нее сложно, скорее упретесь в сеть или винты. В прочем, с помощью небольших доработок можно и тут расшириться.
                      +1
                      It depends. Зависит от того, насколько важен аптайм и скорость. Если не критично, то можно использовать поды типа Backblaze (135Тб за $7400) и распределенную кластерную open-source ФС, что-нибудь вроде Sheepdog, Ceph или Lustre.

                      Я работаю с ZFS — она отлично масштабируется, но только в пределах одной ноды, с failover cluster для HA.
                        0
                        Разница в цене, на сколько я понял обусловлена тем, что в ваших вариантах винты по 2ТБ, а у меня по 4, соотвественно выше плотность, меньше дополнительного обслуживающего железа (контроллеры, платформы). На надежность это не сильно влияет, и как строить на уровне софта это тоже вопрос следующий.
                          +1
                          В одном из вариантов по 2Тб, в другом по 3. Можно и 4Тб использовать, но там с восстановлением массива после потери диска вообще беда — я бы их ставил только в striped 3-way mirror или striped Raidz3. Размер дисков всё растёт, а IOPs — нет.
                            0
                            Ну значит, лучше использовать мое решение выше. Если использовать отдельные сервера, на основновных кроме винтов поставить еще ssd кеш на дисков 6 по 512GB, то вполне реально снимать до 15Г c сервера (120 с 8ми серверов, но это в пике) и объединить эти сервера уже через zfs или подобное (в том числе с теми, что стоят в ДЦ), то все будет работать быстро и надежно, только ssd чтобы поменять придется сервер разобрать (но не выключать)
                              0
                              Хм, может написать пост про варианты архитектуры СХД? Их дохрена, и в каждом свои плюсы и минусы. В общем, есть много вариантов набрать 1Пб стораджа гораздо дешевле, чем Амазон, а спорить о том, какой из них эффективнее для чего, я в 5 утра не готов :) Спать давно пора.
                                +1
                                Полагаю, те, кто готов вложить в СХД порядка 500К найдут специалиста, который все просчитает под их задачу;)
                    0
                    Думается мне, что всяко дешевле чем $1 млн в год
                    0
                    Судя по тому что
                    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 (да и по цене тоже).
                      0
                      Сеть: средняя
                      Скорость I/O с диском: средняя


                      Ну почему нельзя написать в цифрах, ииех.
                        0
                        поскольку тогда их нужно будет соблюдать, а так это относительный параметры — но судя по тому что IOPS в Amazon так себе — то думаю что не очень. Или будет как в Joyent — шаред канал на несколько машин без какого либо гарантированного уровня.
                        0
                        Интересно, как они собираются гарантировать консистентность всего раздела, он ведь явно не на один сервер ляжет. Видимо, будет не особо быстро работать.
                          0
                          думаю будет наоборот — скорость высокой, а вот IOPS низкий.
                          По поводу размера они могут к серверу просто поставить дисковую полку или пробросить SAN внутри ДЦ.
                            0
                            Дисковая полка, даже набитая 4ТБ винтами — это всего 100ТБ. В 10 раз меньше. И это ещё без какого-либо резервирования. Я же говорю, 1ПБ на одном сервере не завести никак, это несколько серверов в сети. А несколько серверов — это проблемы с консистентностью, за решение которых надо платить потерей IOPS и, скорее всего, скорости.

                            В то, что они какой-нибудь NetApp сторадж используют — не верится.
                              0
                              Ну смотрите — если выделить целую стойку или несколько стоит то можно получить и 1ПБ.
                              Консистентность теоретически можно решить если поставить единую точку входа, но при этом правда и надежность тоже будет уменьшена.
                              Я тоже сомневаюсь, но IOPS точно будет низким т.к. в AWS сейчас так и есть.
                                0
                                Я и так знаю, как сделать S3 петабайтового размера, и сколько это будет стоить :) Но при разумном ограничении размера каждого объекта в единицы и десятки гигабайт.

                                А вот как хранить 1ПБ файл (типа образ диска, на котором файловая система), чтобы он был в консистентном состоянии и уметь его восстанавливать — вопрос действительно интересный, и просто набиванием дисками стойки его не решить, тут должен быть какой-то софт. Может быть, специальная файловая система. Или на самом деле хранятся куски файла, а в линкусе специальный драйвер блочных устройств, который требует от хранилища только консистентность на уровне блока. Но про это как-то не пишут :(
                                0
                                Я же говорю, 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.
                                  0
                                  С 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 контроллера в кластере, и коммерческий софт.
                                    0
                                    Потом пропадает питание у ОДНОЙ полки и весь раздел разваливается. Или у вас 32 раздела получается? В каждой полке сколько дисков может вылететь, максимум один? Я уж не говорю про скорость восстановления реида под нагрузкой.

                                    И эта схема не скейлится, 2ПБ уже не сделать никак.

                                    Хотя я сейчас прочитал ещё раз описание сервиса на сайте амазона — тупо 24 диска предлагают, а это уже не интересно совсем.
                                      0
                                      Потом пропадает питание у ОДНОЙ полки и весь раздел разваливается. Или у вас 32 раздела получается?

                                      32 раздела, 11 дисков в каждом (из них 3 можно потерять без потери данных). 2 диска из одного раздела в каждой полке, так что одну можно потерять без особых проблем.

                                      И эта схема не скейлится, 2ПБ уже не сделать никак.

                                      Скейлится прекрасно, минимум до 11 полок (между полками и контроллером два SAS-свича). Кстати, если добить до 11-12 полок, то можно потерять и 3, но тогда совсем хреново будет. 2 — нормально. 11 полок — это 2.6Пб (1.92 usable).

                                      Теоретически можно и больше, но практически после 1Пб usable затык будет уже в контроллере (PCIe, память), так что реально там уже надо будет scale out.
                                        0
                                        Вот система с которой работал на выходных — 14 полок, правда по 24 диска всего. 2 контроллера. 240 3Тб дисков и 120 SSD. i48.tinypic.com/2mlp3.jpg
                                          0
                                          Скейлится прекрасно, минимум до 11 полок

                                          Ну то есть фигово скейлится :) Горизонтальное масштабирование — это когда в разы легко можно увеличить объём. Опять же, вопрос с пропаданием питания на стойке не решён, не всегда можно так делать.

                                          Это я к тому, что вешать много полок на 1 машину — тупиковый путь, подходит только если не надо будет потом увеличивать объём.
                                            0
                                            Так я собственно и говорю, что в какой-то момент без 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 полок на ноду.
                              0
                              Гугл сегодня снизил еще на 10%. Так можете обновить инфу в таблице.

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

                              Что обсуждают

                              Самое читаемое

                              Ваш аккаунт

                              Разделы

                              Информация

                              Услуги

                              © 2006 – 2021 «Habr»
                              Настройка языка
                              О сайте
                              Служба поддержки
                              Мобильная версия