Теоретически, конечно, ничто не будет мешать. Но на практике, мне кажется, в архитектуре OnLive используются «традиционные» связки CPU и GPU, подобные тем, что используются в ПК.
Мне кажется, что все свое время. Когда в регионах появится (а в крупнейших городах он уже есть) надежный высокоскоростной доступ — тогда там можно будет говорить о массовых переходах в публичные облака.
Но уже сейчас даже в регионах пора присматриваться к частным облакам и создавать гибридную инфраструктуру — из традиционных ИТ и облака. А потом уже сюда же легко вольются сервисы из любого публичного облака.
С дисплеем из Vogue вся прелесть заключалась в том, что он был почти бесплатный — поэтому и стал популярным среди любителей поэкспериментировать. А эта штука будет стоить очень немалых денег, скорее всего…
Пока мы говорим Оракл, а подразумеваем Ларри Эллисон, болт ими вполне может быть положен на что угодно. Но что будет, когда Ларри уйдет? Мне кажется этот вопрос занимает менеджмент Оракла больше, чем кого бы то ни было другого.
mister_fog, спасибо за это подробное и объективное освещение последних эпизодов отношений компаний HP и Oracle! В ближайшее время в нашем корпоративном блоге, как и обещали, мы опубликуем еще кое-какие интересные подробности и будем рады увидеть ваши комментарии к ним.;-)
Как и со всеми почти нашими корпоративными продуктами, на эти вещи нет фиксированной цены — каждый наш партнер и реселлер предложит вам разные цены, и цена также может зависеть от объемов вашей покупки.
Но ориентироваться (сравнивать с другими предложениями) можно по сайту hp.com
Компания Oracle сертифицирует работу своих приложений с конкретной версией ОС.
Есть текущая версия HP-UX 11 v3. Есть текущие планы Oracle о доступности приложений Oracle для архитектуры Intel Itanium www.oracle.com/us/corporate/features/itanium-346707.html. Планы именно текущие, т.к. существует высокая вероятность, что Oracle, по многочисленным просьбам заказчиков и антимонопольных комитетов разных стран, скорректирует свои планы и вернет все как было. Текущие версии Oracle могут поддерживаться до 2018 года, а при желании заказчика, вплоть до физического износа сервера, на котором они работают (подробности тут www.oracle.com/us/support/lifetime-support/index.html ).
Серверы HP Integrity — очень надежные и поддерживаются очень долго (10+ лет, а некоторые модели, к примеру HP Superdome поддерживается 17 лет!, подробности тут: www.hp.com/go/hpuxservermatrix ).
Именно надежность оборудования выгодно выделяет HP на рынке бизнес-критичных Unix систем. Новый Superdome 2 был представлен в 2010 году. По надежности он превосходит Superdome первого поколения. Отсюда логично посчитать, что система будет поддерживаться до 2027+ года! Следовательно, при желании, заказчик может запросто развернуть текущие версии приложений Oracle на системах HP Integrity и получать полноценную поддержку как от HP так и от Oracle 2027 года.
Т.е. несмотря на заявления компании Oracle, НР не собирается предпринимать аналогичных шагов и продолжит поддерживать своих заказчиков, у которых на оборудовании и операционной системе НР работают программные продукты компании Oracle.
Возможно, это какой то сетевой протокол, в котором хорошо разбираются сетевые администраторы серверов приложений.
Я за многие годы, будучи сетевым инженером, сталкивался с сотнями различных протоколов, знания по значительной части из них, к сожалению, уже стерлись из памяти. Видимо NFS не самый распространенный протокол в датацентрах.))
Поэтому, это все, на мой взгляд, абсолютно не важно, я думаю не стоит уходить в сторону от обсуждаемого вопроса стекирования IRF. Так как в действительности существует огромная масса существующих протоколов и сетевых приложений, к одним из них в силу специфики их работы важна скорость сходимости, к другим, напротив, не важна.
Главное, что раз требования бизнеса современных ЦОД ставят задачи по быстрой сходимости, значит их необходимо решать.
Хотя… Если предположить, что NFS это Network File System – сетевой протокол доступа к файлам в UNIX системах…
Так или иначе, даже не вдаваясь в детали его технической реализации, это не бизнес критичное приложение, и сходимость сети для его работы не так важна…
Стандартный протокол Spanning Tree (синонимы 802.1D, STP..) служит для того, чтобы на канальном уровне между группой коммутаторов или мостов образовался однозначный путь для пересылки пользовательских пакетов без зацикливаний.
Причем особенность протокола состоит в том, что пока однозначная топология не образовалась т.е. сходимость не наступила – трафик между коммутаторами не передается.
Протокол сходится очень продолжительное время – несколько десятков секунд без применения RSTP и несколько секунд в случае его применения, что для множества современных сетевых приложений просто неприемлимо, для них это фактически отказ в обслуживании. И эти приложения, зачастую, являются еще и бизнес критичными, то есть их остановка даже на непродолжительное время может привести к финансовым потерям в бизнесе, недополучении прибыли, отрицательно сказаться на имидже компании предоставляющая услуги через свою сетевую инфраструктуру.
Поэтому, сходимость топологии сети, является довольно важным фактором, чтобы ему уделять пристальное внимание.
Отдельно хотелось бы сказать о проприетарности протокола IRF.
Тут стоит начать именно с того, что пояснить в двух словах “как оно работает?”
Дело в том, что когда мы хотим обеспечить высокую надежность с точки зрения сети для любого устройства будь то коммутатор, маршрутизатор или сервер отвечающий за бизнес критический трафик, мы среди прочих мер наделяем это устройство резервным сетевым подключением. Таким образом, сетка предназначенная для такого трафика, например сеть современного центра обработки данных, будет вся состоять из подобных двойных подключений. Чтобы при этом не возникало зацикливание трафика, мы можем применить протокол Spanning Tree который заблокирует часть сетевых линков и создаст однозначную топологию для прохождения трафика.
Что будет если мы будем объединять коммутаторы в стек по технологии IRF?
Ответ – наша топология существенно упростится, так как благодаря IRF многие элементы сети состоящие из нескольких физических устройств превратятся в элементы из одного логического устройства. При этом все двойные резервные подключения превратятся в линки точка-точка аггрегированные при помощи стандартного протокола 802.3ad, при этом побочным явлением возникает тот факт, что в такой новой топологии исчезает возможность зацикливания, таким образом протокол Spanning Tree больше не нужен!
Физические же коммутаторы объединенные в стек, при этом работают как одно модульное устройство. Функции IRF при этом можно представить как функции обмена link-state информацией между членами стека, похожими на процедуры программирования интеллектуальных линейных карт управляющим модулем или синхронизации управляющей информации между активным и резервным управляющим модулем в модульных коммутаторах. При этом, совершенно естественно, что скорее всего такой протокол не будет стандартным. Так как маловероятно, что шассийные коммутаторы когда нибудь будет возможно набивать линейными картами различных вендоров.
Не понятна ваша претензия.
Вы просто описываете, что может произойти при медленном схождении.
А в самом блоге говорится, что это негативно влияет на виртуальные машины.
Но уже сейчас даже в регионах пора присматриваться к частным облакам и создавать гибридную инфраструктуру — из традиционных ИТ и облака. А потом уже сюда же легко вольются сервисы из любого публичного облака.
Но ориентироваться (сравнивать с другими предложениями) можно по сайту hp.com
Компания Oracle сертифицирует работу своих приложений с конкретной версией ОС.
Есть текущая версия HP-UX 11 v3. Есть текущие планы Oracle о доступности приложений Oracle для архитектуры Intel Itanium www.oracle.com/us/corporate/features/itanium-346707.html. Планы именно текущие, т.к. существует высокая вероятность, что Oracle, по многочисленным просьбам заказчиков и антимонопольных комитетов разных стран, скорректирует свои планы и вернет все как было. Текущие версии Oracle могут поддерживаться до 2018 года, а при желании заказчика, вплоть до физического износа сервера, на котором они работают (подробности тут www.oracle.com/us/support/lifetime-support/index.html ).
Серверы HP Integrity — очень надежные и поддерживаются очень долго (10+ лет, а некоторые модели, к примеру HP Superdome поддерживается 17 лет!, подробности тут: www.hp.com/go/hpuxservermatrix ).
Именно надежность оборудования выгодно выделяет HP на рынке бизнес-критичных Unix систем. Новый Superdome 2 был представлен в 2010 году. По надежности он превосходит Superdome первого поколения. Отсюда логично посчитать, что система будет поддерживаться до 2027+ года! Следовательно, при желании, заказчик может запросто развернуть текущие версии приложений Oracle на системах HP Integrity и получать полноценную поддержку как от HP так и от Oracle 2027 года.
Т.е. несмотря на заявления компании Oracle, НР не собирается предпринимать аналогичных шагов и продолжит поддерживать своих заказчиков, у которых на оборудовании и операционной системе НР работают программные продукты компании Oracle.
Возможно, это какой то сетевой протокол, в котором хорошо разбираются сетевые администраторы серверов приложений.
Я за многие годы, будучи сетевым инженером, сталкивался с сотнями различных протоколов, знания по значительной части из них, к сожалению, уже стерлись из памяти. Видимо NFS не самый распространенный протокол в датацентрах.))
Поэтому, это все, на мой взгляд, абсолютно не важно, я думаю не стоит уходить в сторону от обсуждаемого вопроса стекирования IRF. Так как в действительности существует огромная масса существующих протоколов и сетевых приложений, к одним из них в силу специфики их работы важна скорость сходимости, к другим, напротив, не важна.
Главное, что раз требования бизнеса современных ЦОД ставят задачи по быстрой сходимости, значит их необходимо решать.
Хотя… Если предположить, что NFS это Network File System – сетевой протокол доступа к файлам в UNIX системах…
Так или иначе, даже не вдаваясь в детали его технической реализации, это не бизнес критичное приложение, и сходимость сети для его работы не так важна…
Причем особенность протокола состоит в том, что пока однозначная топология не образовалась т.е. сходимость не наступила – трафик между коммутаторами не передается.
Протокол сходится очень продолжительное время – несколько десятков секунд без применения RSTP и несколько секунд в случае его применения, что для множества современных сетевых приложений просто неприемлимо, для них это фактически отказ в обслуживании. И эти приложения, зачастую, являются еще и бизнес критичными, то есть их остановка даже на непродолжительное время может привести к финансовым потерям в бизнесе, недополучении прибыли, отрицательно сказаться на имидже компании предоставляющая услуги через свою сетевую инфраструктуру.
Поэтому, сходимость топологии сети, является довольно важным фактором, чтобы ему уделять пристальное внимание.
Отдельно хотелось бы сказать о проприетарности протокола IRF.
Тут стоит начать именно с того, что пояснить в двух словах “как оно работает?”
Дело в том, что когда мы хотим обеспечить высокую надежность с точки зрения сети для любого устройства будь то коммутатор, маршрутизатор или сервер отвечающий за бизнес критический трафик, мы среди прочих мер наделяем это устройство резервным сетевым подключением. Таким образом, сетка предназначенная для такого трафика, например сеть современного центра обработки данных, будет вся состоять из подобных двойных подключений. Чтобы при этом не возникало зацикливание трафика, мы можем применить протокол Spanning Tree который заблокирует часть сетевых линков и создаст однозначную топологию для прохождения трафика.
Что будет если мы будем объединять коммутаторы в стек по технологии IRF?
Ответ – наша топология существенно упростится, так как благодаря IRF многие элементы сети состоящие из нескольких физических устройств превратятся в элементы из одного логического устройства. При этом все двойные резервные подключения превратятся в линки точка-точка аггрегированные при помощи стандартного протокола 802.3ad, при этом побочным явлением возникает тот факт, что в такой новой топологии исчезает возможность зацикливания, таким образом протокол Spanning Tree больше не нужен!
Физические же коммутаторы объединенные в стек, при этом работают как одно модульное устройство. Функции IRF при этом можно представить как функции обмена link-state информацией между членами стека, похожими на процедуры программирования интеллектуальных линейных карт управляющим модулем или синхронизации управляющей информации между активным и резервным управляющим модулем в модульных коммутаторах. При этом, совершенно естественно, что скорее всего такой протокол не будет стандартным. Так как маловероятно, что шассийные коммутаторы когда нибудь будет возможно набивать линейными картами различных вендоров.
Вы просто описываете, что может произойти при медленном схождении.
А в самом блоге говорится, что это негативно влияет на виртуальные машины.