Red Hat выходит на рынок «Big Data»

Автор оригинала: Steven J. Vaughan-Nichols
  • Перевод
В начале месяца вышел релиз Red Hat Enterprise Linux 6.2, в котором особое внимание уделено хранению данных. Теперь понятно почему — Red Hat выходит на новый для себя рынок, рынок больших данных («big data»). После того, как Red Hat купил Gluster, я опубликовал некоторые свои мысли о том, для чего сделана это покупка. Но я не мог даже представить, что новый продукт у Red Hat появится всего-лишь спустя два месяца, после анонса сделки..

Одна из причин, почему Red Hat станет первой Open Source компанией с оборотом в миллиард долларов, это то, что она занимается не только дистрибутивом Linux, но и многими другими вещами, связанными с Linux, такими как облачные вычисления, виртуальные десктопы (VDI), Java Enterprise и теперь, с выходом Red Hat Storage Software Appliance, управлением большими данными.

Вы спрашиваете, что такое большие данные? Предприятия недавно осознали факт того, что мы тонем в больших данных. Ежедневно мы генерируем 2.5 квинтиллиона байт данных, а 90% всей информации в мире было создано за последние два года. Эти данные поступают отовсюду: записи об изменении погоды и климата, сообщения в социальных сетях, цифровые фотографии и видеозаписи, транзакции онлайн-покупок и сигналов GPS с сотовых телефонов. Все это — большие данные.

Как же управлять таким количеством данных? Чтобы справится с «big data», Red Hat купила Gluster, открытое решение для хранения данных, и использовала его для создания нового программного продукта. Storage Software Appliance “расширяет продуктовую линейку Red Hat с помощью ведущего в отрасли решения для управления неструктурированными данными и их хранения”.

Возможно, вы подумали, что Red Hat купила Gluster для собственного OpenStack–облака? Думаю, что частично это именно так. Но теперь мы можем видеть, что GlusterFS интересовал Red Hat и как самостоятельный продукт — открытая, распределённая файловая система способна к масштабированию до нескольких петабайт.

Red Hat Storage Software Appliance основан на GlusterFS 3.2 и Red Hat Enterprise Linux (RHEL) 6.1. Это программное обеспечение, которое позволит предприятиям перейти к виртуализированному, стандартизированному и масштабируемому пулу хранения данных, что обеспечит гибкость, производительность и качество обслуживания, необходимое для успешной работы современной корпоративной среды.

В заявлении, сделанном Ранго Рангачари (Ranga Rangachari), главным менеджером систем хранения Red Hat, говорится: «Сейчас важное время для Red Hat, мы представляем наш первый релиз инновационной системы хранения. Мы ожидаем, что анонсированный продукт станет одним из способов значительного снижения расходов на хранение данных для предприятий, столкнувшихся с огромным ростом количества неструктурированных данных. Мы предлагаем таким компаниям систему хранения данных с открытым исходным кодом, а наши разработчики продолжают разрабатывать новые решения и расширять инновации в продуктах.»
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

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

    0
    Какая-то неприкрытая реклама, напоминающая типичный пресс-релиз. Фу.
      +4
      Так половина текста — это и есть цитаты из пресс-релиза (то, что в кавычках). =)
      Это не я писал, я просто перевёл — хотел донести новость о том, что Red Hat выходит в новый для себя сегмент рынка, прошу прощения, если текст слишком уж… маркетинговый.
        0
        Ну да, маркетинговый получился. Как верно заметили ниже — без деталей неинтересно.
        +16
        RedHat не нуждается в рекламе.
          0
          Даже хороший продукт нуждается в рекламе.
            +2
            Наверное именно потому что они так не думают они и стали компанией с миллиардным оборотом :)
          +3
          Молодцы Red Hat развиваются стабильно.
            +2
            У меня гластер не вызвал ощущения особой производительности. Возможно, я «не в тех условиях» тестировал, но в качестве высокопроизводительной СХД оно не годится.
              +2
              Я вам говорю, как человек с опытом работы с ФС на больших кластерах — в крупных системах почти всегда очень большое значение имеет «тонкая настройка», т.е. по-простому «прямые руки». Поэтому, я бы на вашем месте не стал обобщать… ведь вы же на свой «страх и риск» тестировали, без официальной поддержки непосредственных разработчиков?..
                +2
                У меня очень специфичные запросы — мне нужно просто ДОФИГА И ДЁШЕВО иопсов на очень рандомных данных. А так же защита от сплитбрейна, active/active конфигурация и т.д.

                Если эта штука не способна выдать хотя бы 5-8к иопсов с 30 саташных винтов (при небольшом ssd-кеше), то я её бракую как «не имеющую особой производительности».
                  +5
                  А не многовато хотите? Даже если взять, что диск выдает 100 iops, то получается не больше 3000 при самом оптимистичном прогнозе (страйп из всех дисков).
                    0
                    Не «хочу», а юзаю. Мы когда искали решение для СХД, гластер щупали в т.ч. Остановились на блочном уровне, благо там всё сильно проще.
                      +1
                      Я всё равно, как и предыдущий автор, не понимаю как на «очень рандомных» данных (априори предполагающих бессмысленность [SSD-] кеша) вам удаётся столько иопсов выжать. Поделитесь?
                        0
                        Хех, ну тут всё просто, на самом деле. ssd-кеш решает главную проблему — write-random превращается в почти линейную запись (на которой SATA внезапно показывает аж 1.5k IOPS за раз, что похоже на линейную скорость записи, плюс fast rewrite, так что многие IO не доходят до SATA). С чтением сложнее, но кеш всё-таки делает свою работу.

                        Как это сделано… Ну, если в кратце — flashcache.
                          0
                          Спасибо. Значит, flashcache уже в продакшене работает, надо будет потестировать.
                            0
                            Ну, я пару раз натыкался на то, что он не признаёт свой собственный кеш, но в условиях кластеризации его «развал» — всего лишь ресинк. В работе я ни разу проблем не видел.
                  0
                  Тонкая настройка != допиливание исходного кода. Одно дело крутить ручки, которые поддержка рекомендует крутить в этом конкретном случае (это если продукт не пионерский, и у него есть нормальная поддержка), а другое дело разбираться в тонкостях организации файловой системы, читать сорцы, и находить нужные настройки (хорошо, если они не в виде #define). Второй подход конечно тоже имеет право на существование, но не в энтерпрайзе.
                    +2
                    Я поддерживал решения с хранилищем на GlusterFS. С официальной поддержкой от непосредственных разработчиков. Несколько не связанных инсталяций. GlusterFS для нас был КУЧЕЙ геморроя. Яркий представитель индусского кодопроизводства. В RH серьезные инженеры и может доведут до ума. Но я как вспомню, так взрогну.

                  0
                  Заглянув в релизноты появился вопрос — эта штука лишь отвечают за репликацию данных между нодами и доступ к ним, а за сохранность их на самой ноде отвечает серверный raid-контроллер?
                  Тоесть это не аналог ZFS, а нечто вроде DRBD+GFS?
                    +1
                    Вообще, очень не хватает технических деталей. Хотя бы на примере существующих внедрений (где, как и для чего используют), а то получается новость одной строкой: «RH выпустил свой Storage Appliance, заходите на посмотреть».
                      +4
                      GlusterFS работает на уровне файлов. Т.е. когда мы пишем в неё файл, он полностью записывается на один из (рандомных) нодов glusterfs. Это что-то вроде автоматического рсинка, который распределяет файлы между нодами. При необходимости можно настроить поведение так, что один файл будет писаться на несколько нод (репликация).

                      Клиент glusterfs работает в пользовательском пространстве (fuse).

                      Совокупность этих подходов даёт крайне низкую производительность. Особенно она проявляется на больших файлах и при настроенной репликации. Поэтому для серьёзных вещей glusterfs не очень пригоден. Его можно использовать лишь как очень-очень медленное, но легко масштабируемое в ширину решение.
                        0
                        Большое спасибо за развёрнутый ответ.
                      +1
                      Если нужна избыточность данных на ноде, то использование софтвартного миррора (md) никто не отменял. Но вот зачем? Проще неизбыточных нод поставить избыточное количество (и это не 2*N как в случае с миррором) — дешевле выйдет. ZFS сильно прожорлив особенно по памяти, в случае с glusterfs можно обойтись достаточно дешевыми машинами с минимумом памяти.
                        0
                        Меня смутило, что в системных требованиях указан аппаратный рейд контроллер с батарейкой. Похоже, RH видит систему именно такой, а софтрейды в любом виде записываются в unsupported.
                          +1
                          Им нужна хорошая производительность на запись, что у любого вендора будет через контроллер с кешем, а раз контроллер с кешем, то на нем должна быть батарейка, так как ни одному вендору ни в одно место не уперлось отвечать за потерянные данные в случае power loss.
                            0
                            Про батарейку понятно, правда указание лишь FBWC без обычного BBWC выглядит странновато :)
                      +1
                      Удобный маркетинговый термин — «big data». Как хочешь, так и повернешь. Ровно как в этом посте, никаких данных о возможностях. Если например в изилон сразу говорят, что могут один том объемом 15 Пб делать, то здесь вообще ни о чем.

                      Больше всего забавляет, что определения «больших данных», как такового не существует. Есть нечто полуобъективное в википедии, с которым лично я больше всего согласен, но все вендоры трактуют это понятие как хотят. Отдельные, могут трактовать в рамках одного вендора по разному, где как удобнее с коммерческой точки зрения.
                        0
                        Ну это примерно как «на порядок», которое, в зависимости от желания говорящего, может варьироваться от 15% до 100500 раз :)

                        Не будьте строги к тексту из прессрелиза. :)
                          0
                          Я не строг. Я глумлюсь :)
                            0
                            Пресс-релиз пишется как SEO-текст для ботов. Там главное — «ключевики», смысл текста в целом — вторичен :)
                            –1
                            порядок величины при этом — вполне строгий математический термин
                          +1
                          Подождите-подождите. Это ли не настоящая отказоустойчивое распределенное файловое хранилище?
                          У меня есть 20 серваков, в каждом по 4 локальных веника. Я хочу из этого барахла сделать сетевой аналог RAID10. Так, чтобы отказ одной машины не приводил к падению кластера.
                          В свое время gluster мне показался черезчур тяжелым по CPU, а Lustre не имела возможности репликации.

                            +2
                            Нихрена не понять об чём речь. Это БД, файловая система, block storage? Зачем переводить на хабр откровенно маркетинговый текст, не имеющий ничего общего с технологий?

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

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