LINUX.ORG.RU

Red Hat Storage Server 2.0

 


0

2

На своём ежегодном саммите компания Red Hat анонсировала Storage Server 2.0. В основе этого продукта лежат Red Hat Enterprise Linux (RHEL) 6 и GlusterFS 3.3, а предназначен Storage Server для реализации NAS-решений (Network-Attached Storage). Среди наиболее заметных изменений — различные функции повышения доступности данных.

Новая версия «Unified File and Object Storage» (UFO) позволяет получить доступ к данным, как к объекту (как S3 или аналогичные API-интерфейсы) или как к файлу (примонтированные как POSIX-совместимая файловая система).

Новый менеджер блокировки сети (network lock manager, NLM) предназначен для синхронизации в случаях, когда несколько клиентов хотят получить доступ к файлу через NFSv3; также были добавлены автоматическое восстановление IP для NFS (Network File System) и CIFS (Common Internet File System).

Как и RHEL, Storage Server 2.0 предлагает несколько новых Technology Previews функций (неподдерживаемые технологии, для предварительного ознакомления), в числе которых Hadoop-совместимый API для доступа к данным, поддержка RDMA (Remote Direct Memory Access) и web-консоль для управления Red Hat Storage 2.0.

В варианте «on-premise» Red Hat Storage позволяет создать NAS, используя стандартные x86-сервера, которые, по словам разработчиков, могут быть легко расширены за счет добавления новых систем. Эти системы могут состоять из виртуальных машин, которые работают в публичных или гибридных облаках — Red Hat предлагает отдельные варианты Storage для этих сценариев.

Red Hat Storage NAS, работающий на нескольких системах, будет выглядеть как единое целое для конечных пользователей. Продукт использует файловую систему XFS для локального хранения данных, поэтому получить доступ к данным, хранящимся в Red Hat Storage можно через CIFS, NFS, HTTP и OpenStack Swift. Более полный обзор новых возможностей Red Hat Storage Server 2.0 можно найти здесь.

>>> Подробности

★★★

Проверено: maxcom ()

стандартные x86-сервера

А NAS'ы на ARM не эффективнее будут? Менее энергозатратны при достаточно хорошей производительности.
И да, почему XFS?

sT331h0rs3 ★★★★★ ()

почему нет iSCSI - шапошники не осилили?

GOD ★★★ ()

Это всë больше похоже на proof of concept, чем на действительно нужное решение. Интересно, где это всë может использоваться?..

cruxish ★★★★ ()
Ответ на: комментарий от sT331h0rs3

И да, почему XFS?

Кстати, да, хороший вопрос. Я помню, что RH были к ней не очень лояльны.

cruxish ★★★★ ()

Red Hat Storage NAS, работающий на нескольких системах, будет выглядеть как единое целое для конечных пользователей. Продукт использует файловую систему XFS для локального хранения данных, поэтому получить доступ к данным, хранящимся в Red Hat Storage можно через CIFS, NFS, HTTP и OpenStack Swift. Более полный обзор новых возможностей Red Hat Storage Server 2.0 можно найти

Как способы доступа данных, хранящихся в распределённом хранилище могут зависеть от того, какая файловая система используется для локального хранилища?

В оригинале написано иначе: «The POSIX compatible GlusterFS servers, which use XFS file system format to store data on disks, can be accessed using industry standard access protocols including NFS and CIFS. » Т.е. «Распределенное хранилище GlusterFS использует XFS для хранения данных на дисках. Данные GlusterFS могут быть доступны с использованием стандартных протоколов.»

rtvd ★★★★★ ()
Ответ на: комментарий от vasily_pupkin

Тогда уж на MIPS

Чем оно лучше чем ARM для этой задачи?

rtvd ★★★★★ ()
Ответ на: комментарий от GOD

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

dyasny ★★★★★ ()
Ответ на: комментарий от cruxish

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

dyasny ★★★★★ ()
Ответ на: комментарий от GOD

Таки да, iSCSI улыбнуло.

Вообще, сложилось мнение, что шапочники просто впихали в дистрибутив кучу всего, что есть. А конечного продукта как небыло, так нет и не будет.

wheel ()
Ответ на: комментарий от wheel

Таки да, iSCSI улыбнуло.

каким образом NAS относится к iSCSI?

Вообще, сложилось мнение, что шапочники просто впихали в дистрибутив кучу всего, что есть. А конечного продукта как небыло, так нет и не будет.

и поэтому ebay, amazon и pandora (из более известных) пользуются этим продуктом, которого не было и не будет.

лор-аналитики такие лор-аналитики

dyasny ★★★★★ ()
Ответ на: комментарий от dyasny

и поэтому ebay, amazon и pandora (из более известных) пользуются этим продуктом, которого не было и не будет.

Именно RedHat Storage Server 2.0?

tailgunner ★★★★★ ()
Ответ на: комментарий от dyasny

каким образом NAS относится к iSCSI?

Может, там удобно хранить образы? :) ну вот, например: http://80.77.82.75/video/iscsi-xp64.mp4

пользуются этим продуктом, которого не было и не будет

Да-да-да!!! И никакой обработки напильником! ebay работает искаропки.

wheel ()
Ответ на: комментарий от tailgunner

если печатают новости с RH Summit, то могут печатать все о чем там говорилось, а не выборочно

dyasny ★★★★★ ()
Ответ на: комментарий от wheel

Может, там удобно хранить образы? :) ну вот, например: http://80.77.82.75/video/iscsi-xp64.mp4

еще раз, iSCSI и NAS, wtf?

Да-да-да!!! И никакой обработки напильником! ebay работает искаропки.

понятно, представления о сказанном ноль.

dyasny ★★★★★ ()
Ответ на: комментарий от dyasny

ebay, amazon и pandora (из более известных) пользуются этим продуктом, которого не было и не будет.

Именно RedHat Storage Server 2.0?

если печатают новости с RH Summit, то могут печатать все о чем там говорилось, а не выборочно

ЛОР-аналитики такие аналитики.

tailgunner ★★★★★ ()
Ответ на: комментарий от wheel

iscsi это блочный доступ! В новости речь о файловом хранилище. Хотя, все-же вы правы, сегодня крайне модно делать unified storge

anonymous ()
Ответ на: комментарий от anonymous

делать unified storge

Да вот и я про то же. Образы хранить удобно. И управлять ими тоже.

wheel ()
Ответ на: комментарий от wheel

glusterfs это в первую очередь fs, какой тут может быть блочный доступ?

dyasny ★★★★★ ()
Ответ на: комментарий от tailgunner

ЛОР-аналитики такие аналитики.

это да. а я на этом саммите был, и представители этих фирм там показывали как они пользуются glusterfs на RHES, и демонстрировали roadmap-ы по переходу на с первой версии 2.0

dyasny ★★★★★ ()
Ответ на: комментарий от wheel

попробуйте сравнить скорость tgtd или LIO с диска или LV по сравнению с использованием файла как backing store.

dyasny ★★★★★ ()
Ответ на: комментарий от dyasny

главное что бы ты понимал о чем речь, и возможно начнешь троллить профессиональнее

GOD ★★★ ()
Ответ на: комментарий от anonymous

Учитывая что давно существует технология iSCSI LUN Regular file

и во всех виндовсах (не говоря уже об linux) есть iSCSI initiator'ы «из коробки» вполне можно было бы и реализовать какой полезный и удобный компонент ИМХО

GOD ★★★ ()
Ответ на: комментарий от GOD

и во всех виндовсах (не говоря уже об linux) есть iSCSI initiator'ы «из коробки» вполне можно было бы и реализовать какой полезный и удобный компонент ИМХО

нормальный таргет появился в линуксе совсем недавно, если конкретнее то только в 17ой федоре.

в RHEL он тоже есть, но как tech preview, и емнип только для FCoE. Продуктизировать это пока еще нельзя

dyasny ★★★★★ ()
Ответ на: комментарий от dyasny

а я на этом саммите был, и представители этих фирм там показывали как они пользуются glusterfs на RHES, и демонстрировали roadmap-ы по переходу на с первой версии 2.

То есть насчет 2.0 только роадмапы. Мог бы не ломаться, а сразу сказать.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

его две недели как анонсировали, но все уже на него проапгрейдились, ага. логику надо иногда включать.

dyasny ★★★★★ ()
Ответ на: комментарий от dyasny

логику надо иногда включать.

Назвался Ъ-экспертом - ответь на вопросы. А ты вместо четкого ответа ломаешься, как пятикопеечный пряник.

tailgunner ★★★★★ ()

используя стандартные x86-сервера

Разве не серверЫ в множ числе? Вроде как повседневно используемое слово... А то получается, что принтера, компьютера, драйвера, монитора :D

vovans ★★★★★ ()
Ответ на: комментарий от vasily_pupkin

Стучит быстрее

А надо стучать быстрее?

rtvd ★★★★★ ()

Предъявы по iscsi смешные. Изучайте отличие file level от block level. Решение не того уровня чтобы тащить в него вообще технологии доступа. iSCSI предъявляет некоторые специфические требования к ethernet свитчам да и к самому софту, так для блочных устройств требуется низкое время отклика. А если вы для медленного доступа к файлам юзаете iscsi то это забивание гвоздей пасатижами.

А решение само оригинальное, им бы еще партнерство с hp по серверам заключить и продавать аплаенсы. Был бы такой left hand только NAS/CAS.

testuser123 ()
Ответ на: комментарий от tailgunner

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

dyasny ★★★★★ ()
Ответ на: комментарий от testuser123

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

насчет же низкого времени отклика, то система поддерживает RDMA, куда уже ниже?

dyasny ★★★★★ ()
Ответ на: комментарий от dyasny

Просто поддержка iSCSI есть у многих поставщиков готовых NAS решений. Я сам использую x86 NAS от QNAP, имеется множество вариантов iSCSI загрузки различных ОС.

Да и раз продукт назвали Storage Server, то почему бы и не добавить Storage area network (SAN)?

В некотором Вы правы, обычно для SAN отводится отдельное сетевое хранилище, но ведь сейчас все экономят, не так ли?

lexius ★★ ()
Ответ на: комментарий от lexius

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

Можно конечно выдавать iscsi с файлом как backing store, но во первых скорость такого решения обычно очень далека от требуемого от блочного доступа в рабочей среде, а во вторых, таргет способный по настоящему хорошо давать iscsi в линуксе еще не попал в RHEL официально - сыроват он. Надеюсь в 6.4 или 6.5 добавят, после того как он в 17ой федоре пройдет серьезный цикл проверок

dyasny ★★★★★ ()
Ответ на: комментарий от Quasar

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

Ylytch ()
Ответ на: комментарий от GOD

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

Ylytch ()
Ответ на: комментарий от dyasny

Ты забыл сказать как минимум двух вещах. Первое, что отданный по iSCSI LUN после форматирования мгновенно обременится всеми ограничения наложенными на него гостевой файловой системой,. Второе, чтобы получить вменяемый SAN на iSCSI изначально неплохо бы вместо software target юзать нормальный и ни разу не дешевый hardware offload HBA, плюс озаботится вменяемым multipath. Все это в принципе противоречит идеологии простого, отказоустойчивого решения с быстрым и несложным масштабированием. В любом раскладе, боюсь, люди просто не понимают тебя))))

Ylytch ()
Ответ на: комментарий от dyasny

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

Если вы не поняли ещё, что в UNIX всё - файл, в том числе и «блочное устройство», мне вас жаль. Действительно, индустрия уходит от понятий NAS и SAN и уже давно оперирует понятием Unified Storage. Если наша недоразвитая IT-индустрия работает на нефтяников и на бухглатерш в 1С-ом, это ещё не значит, что нельзя иногда всякие умные ресурсы читать, да и в принципе мозгами шевелить немного - хотя бы для собственного развития. Разделение на NAS и SAN было актуально тогда, когда под Linux не было ни одного нативного iSCSI Target, сейчас их минимум пять, и все абсолютно рабочие. Мало того вы ещё найдите такой NAS, который не имеет iSCSI Target'а.

DRVTiny ★★★★★ ()
Ответ на: комментарий от DRVTiny

таки Unified Storage это не уход от понятий NAS и SAN, а таки реализации системы хранения таким образом, чтобы одновременно оперировать и NAS и SAN в пределах одной системы хранения как Single Management Point. Если походить более строго, это еще и возможность использования для одних и тех же логических единиц хранения как блдчного так и файлового доступа, пусть и не одновременно. «a unified storage system consolidates file-based and block-based access in a single storage platform and supports fibre channel SAN, IP-based SAN (iSCSI), and NAS (network attached storage)». Понятие давно тоже очень большое натягивание совы на глобус. Из серъезных игроков давно с NUS на рынке присутствует только NetApp, да с натяжкой Sun/Oracle Unified Storage 7xxx. Остальные IBM V7000 & всяческие там Хитачи и с очень большой натяжкой EMC VNX - появились год два не более Наличие в классичеcком NAS софтверного iSCSI его NUS не делает.

Ylytch ()
Ответ на: комментарий от dyasny

Dude, как можно сравнивать софтверное решение и такой классический хардварный True Enterprise как Isilon? Задача то вроде одна, но абсолютно для разных ниш рынка.

Ylytch ()
Ответ на: комментарий от Ylytch

и да и нет :) отданный LUN вполне можно использовать как LVM, что намного гибче просто ФС.

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

ну а люди... не ЛОРом единым :)

dyasny ★★★★★ ()
Ответ на: комментарий от DRVTiny

Действительно, индустрия уходит от понятий NAS и SAN и уже давно оперирует понятием Unified Storage.

дада, научите меня сирого

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

к «вашей» индустрии я имею мало отношения, кроме разве что некоторых клиентов в России.

Разделение на NAS и SAN было актуально тогда, когда под Linux не было ни одного нативного iSCSI Target, сейчас их минимум пять, и все абсолютно рабочие.

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

пока что только LIO это может, но он еще не поддерживается в RHEL

dyasny ★★★★★ ()
Ответ на: комментарий от Ylytch

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

RHES для настоящего scale out покупают под определенное железо (UCS например отлично подходит), а не под наколенные поделки. Просто надо смотреть на все немного иными категориями чем местные деятели для которых и голая кость^W^W два десктопа с drbd и экспортом в nfs и tgt - мега-сторедж

dyasny ★★★★★ ()

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

Фуфло это все, различия только в юридическом статусе - насколько важен результат работы этих всех железок и насколько посадят админа если все будет часто глючить. Через 4-5 лет это все будет в десктопах игроманов за 500 баксов (при условии что облака все не сожрут к тому времени - всякое бывает)

anonymous ()
Ответ на: комментарий от vovans

Разве не серверЫ в множ числе? Вроде как повседневно используемое слово... А то получается, что принтера, компьютера, драйвера, монитора :D


Разрешается говорить и так, и так.

blackst0ne ★★★★★ ()
Ответ на: комментарий от dyasny

Каким это местом CiscoUCS определяет storage scalability? При всех своих достоинствах это чисто калькулейт платформа+ network среда. Бэкэнд систему хранения под него предоставляет внешнее решение NetApp/EMC. При все моей любви к UCS, в любых раскладах , где тут RHES?

Ylytch ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.