Ого! Нужно записаться.

Вообще интересно будет послушать. У меня конечно есть конкурентное решение, но вдруг я неправ?

ceph?

По ссылке 15th October 2014

а записи потом выкладываются в свободный доступ?

В свободный доступ за скромную плату.

Red Hat Storage — комплексному программному решению NAS для современных центров обработки данных, виртуальных и облачных сред.

Зачем, когда есть FreeNAS и облачный Гугл переплачивать за какие то нерациональные решения?

За техническую поддержку?

То есть ты хочешь сказать назуй админов, дадим РедХатовцам буржуазным работу? //Если не врубился, то выгоднее, проще и секьюрнее содержать штатного админа, чем пользоваться услугами корпораций, открыто сотрудничающих с АНБ.

Одно другому не мешает. У нас например не мешает.

У нас например не мешает.

У вас это где?

Одно другому не мешает.

А поконкретнее? Или вы таки любитель платить дважды?

может все таки стоит разобраться в решении перед тем как писать чушь?

Почему вы не аргументированно называете мои слова чущью? Может это вы не понимаете того, о чем пишете? Ну и что же это за решение по-вашему?

RHS это оттестированная версия GlusterFS, scale-out storage, который никаким местом не относится к стандартной категории NAS вроде freenas/openfiler/nexenta/etc.

гуглевские сервисы это вообще SaaS, и IaaS, и если в последнем и есть элементы хранения данных, то они опять же никакого отношения к private cloud не имеют.

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

Какое значение вся чущь, которую вы написали имеет для конечного пользователя?Одно другому не мешает.

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

Дак я как технический специалист и заявляю, что решение от Ред Хата дорогое, неконкурентоспособное, да и бессмысленное + еще отнимает хлеб у вменяемых админов в пользу сотрудников RH. А RH как известно фирма буржуазная, зачем поддерживать экономику америки, когда можно поддержать Русскую экономику и Русских админов?

http://goo.gl/hQJtla

Ну, GlusterFS - это распределенная ФС. Вот границы применимости (особенно, в организации среднего масштаба не связанной с ИТ), на мой взгляд, весьма узкие - файловое хранилище с репликацией по сети на уровне ФС, доступ к файлам с любой из нод (что, конечно, очень круто), но на этом сильные стороны заканчиваются.
СУБД поверх GlusterFS, похоже, не погоняешь.
RadHat про QEMU’s GlusterFS block driver заливает - говорят, что производительность IO виртуальной машины с образом блочного устройства на GlusterFS близка к таковой при образе на локальной ФС (а ведь тут мы получаем еще и живую миграцию!). И это второй сценарий использования (если платформа виртуализации на RHEV т.е. на qemu+kvm). Единственный минус в том, что честное блочное устройство (например, логический том), проброшенный в виртуалку, все равно, быстрее образа на ФС, даже на локальной. Хотя, для инфраструктурных серверов, особая производительность и не нужна.

Где срач на тему почему системд сакс?

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

Ну, GlusterFS - это распределенная ФС.

распределенность это только составляющая от главной идеи. вам такое понятие как scale-out что то говорит?

RadHat

кито?

И это второй сценарий использования

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

если платформа виртуализации на RHEV т.е. на qemu+kvm

RHEV это намного больше чем просто qemu+kvm, ну да не будем отходить от темы

Единственный минус в том, что честное блочное устройство (например, логический том), проброшенный в виртуалку, все равно, быстрее образа на ФС, даже на локальной

если том доставлен по все еще очень распространенной 2/4Гб FC a локальнaя ФС на 6Гб SAS? оверхед от прохода через ФС не настолько серьезен

первое ключевое слово тут - масштабируемость. второе - доступность. с такой ФС, когда у меня кончается место, я могу добавить еще хост с дисками, и просто расширить том, да еще и прибавить к производительности. надо еще - пихаем еще сервер в стойку и все. Никаких дополнительных полок, контроллеров и прочих заморочек, все максимально просто, доступно, и расширяемо ad libitum. Такое не сделаешь на freenas, и не получишь где-то там в облаке, когда файлы нужны здесь и сейчас. репликация нужна для того чтоб при отказе хоста данные не терялись, а не чтоб конкурировать с какой-нибудь drbd. разница просто огромная, но чтоб врубиться, надо мыслить именно такими масштабами, где сотня хостов в кластер добавляется за пару дней, по мере надобности, и это повседневная задача а не проект пятилетки, а ВМ на всем этом появляются и исчезают тысячами

Такое не сделаешь на freenas, и не получишь где-то там в облаке

И Вы называете себя техническим специалистом?

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

АХАХХАХАХАХАХАХАХА - АААААААААААААААААААААА ХАХАХАХАХАХ

бедняге анонимусу порвало воображение

зачем поддерживать экономику америки

Очевидно же - софт с адекватной поддержкой требует гораздо меньше Русских Админов, которых можно сократить, и перевести на строительство Русских Дорог, что даст Русской Экономике гораздо больше пользы, чем попытки повторять в домашних условиях то, что уже и так сделано злобными забугорщиками.

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

Во-вторых, локальная ФС - это не обязательно ФС на локальных дисках, а том - не обязательно том на СХД. Я бы предложил воздержаться от утверждения о превосходстве одного механизма предоставления доступа к данным (ФС) над другим (raw) на основании мысленных экспериментов, а также от измерения производительности подсистемы ввода-вывода гигабитами интерфейса.

Мы говорим про оверхед использования ФС (пусть даже локальной, например, ext*) для предоставления блочного стораджа виртуальной машине. Он есть и он значительный.

Также, не стоит забывать, что доступ к данным на GlusterFS с хостов-гипервизоров осуществляется по сети (но, в организации добавляющей 50 сторадж узлов в кластер каждый день (и имеющей 2Гбит SAN?), наверное, все же инфинибэнд).

Основная выгода, это платная техподдержка. Но техподдержка это не аутсорсинг, по этому админы внедряют, настраивают и сопровождают продукт, а техподдержка занимается своим делом. Например база падает по не известным причинам, вы обращаетесь в техподдержку, они изучают проблему и выдают вердикт типа баг в субд исправят тогда-то и тд. Так работает любая вменяемая техподдержка. И да, на Русских Сисадминов нам обсолютно всеравно =)

Вы не Русский?

Скорее не россиянин

эээээ? С каких это пор контора Брина начала предоставлять услуги IaaS?

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

фирма называется Red Hat, не redhat, RedHat, Radhat и прочие вариации на тему.

Во-вторых, локальная ФС - это не обязательно ФС на локальных дисках, а том - не обязательно том на СХД. Я бы предложил воздержаться от утверждения о превосходстве одного механизма предоставления доступа к данным (ФС) над другим (raw) на основании мысленных экспериментов, а также от измерения производительности подсистемы ввода-вывода гигабитами интерфейса.

можете предлагать что угодно, только опыт менее десятилетней давности утверждал что DAS быстрее чем SAN. с тех пор конечно появился набор технологий, как в сетях на 10/40/100Gb так и FC с 8/16Gb, плюс IB, но те технологии все еще очень широко используются, и те факты остаются фактами и сейчас.

Мы говорим про оверхед использования ФС (пусть даже локальной, например, ext*) для предоставления блочного стораджа виртуальной машине. Он есть и он значительный.

да ну? и насколько он значительный? хотялось бы посмотреть на серьезный сравнительный анализ, а то когда мы его делали два года назад, после некоторых оптимизаций примененных к qcow2, разница оказалась исчезающе мала по сравнению с raw LV

Также, не стоит забывать, что доступ к данным на GlusterFS с хостов-гипервизоров осуществляется по сети (но, в организации добавляющей 50 сторадж узлов в кластер каждый день (и имеющей 2Гбит SAN?), наверное, все же инфинибэнд).

да, по сети. и каждый простой гигабитный линк дает еще один канал к куску стореджа, ускоряя суммарную скорость доступа. это еще один компонент scale-out

https://cloud.google.com/products/compute-engine

охренеть. Век живи, век учись, дураком помрешь.

Ну вы хоть сейчас то понимаете, что этот ваш РыдХат просто сливает сотрудничеству Canonical & Google?

рыд?

кому он сливает и каким образом? с google сотрудничество тоже есть, и еще много с кем. Или вы всерьез считаете canonical серьезным игроком в серверных ОС?

Parallels Cloud Server

А мы используем Parallels Cloud Server. На нем в отличие от GlusterFS можно и базы данных гонять, и виртуализацию. А с SSD кэшированием вообще хорошо работает...

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