Конференция «Дорога в облака», посвященная OpenStack & Big Data

Это канал для загрузки данных в облако и выгрузки результатов, управления облаком и удаленных подключений к виртуалкам. Для этого такого канала вполне хватает.

«загрузка данных» может создавать гораздо больший поток, чем 200 мегабит. А ещё данные должны загружаться быстро. Если их, например, 20 гиг, то 200 мегабит - это очень мало.

«загрузка данных» может создавать гораздо больший поток, чем 200 мегабит.

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

200 мбит/c, это грубо говоря, 20 мбайт/с. 20 Гигабайт данных при такой скорости копируется за 20 мин, что более, чем достаточно, если учесть, что время просчета таких заданий явно будет исчисляться сутками, если не больше...

У меня получается 20 гиг за 10 минут. Но все равно приятнее, когда ничего никуда копировать не надо - взял cad и построил модель прямо в облаке, взял ансис и построил сетку, посчитал по сетке все, что захотел, посмотрел результат и скопипастил ключевые параметры в отчет.

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

Но все равно приятнее, когда ничего никуда копировать не надо - взял cad и построил модель прямо в облаке, взял ансис и построил сетку, посчитал по сетке все, что захотел, посмотрел результат и скопипастил ключевые параметры в отчет.

Тут мне кажется легко обмануться словами. Что значит модель в облаке? Облако разделено на узлы и при этом расчетные узлы аппаратно сильно отличаются от узлов, на которых можно эффективно запускать настольные 3d приложения.

То есть в любом случае придется данные перекидывать с узла на узел. Общий сетевой сторадж на все облако? Ну честно говоря, не сходятся у меня циферки экономичности и скорости. Облако эффективно, когда в нем много узлов, а даже 10 узлов по 20 виртуалок поставят на колени любой сетевой сторадж. А если посчитать цену такого стораджа, то получается не просто медленно, но еще и дорого. Вообще финиш.

Гораздо дешевле и скоростнее иметь на каждом узле локальный железный быстрый раид для виртуалок, который кушает только эта нода и общий сетевой сторадж для библиотек образов и бекапов и прочих сервисных штук, то есть для того, что используется относительно редко. Такой сторадж совсем иное дело, он стоит вменяемые деньги ибо это просто nfs ибо это просто ethernet 1/10G.

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

Вообще ваш подход выглядит разумно.

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

А сколько стоража у вас в облаке, сколько памяти и сколько процессоров? Хотя бы порядки, если вдруг это закрытая информация.

Да секрет не очень большой, в корпоративном облаке порядка 300Т, которые организованы в 10 раиды для оперативных ланных и 6 раиды для целей хранения нечасто используемых данных. Ну и в амазоне порядка 50Т ибо дорогонько там все у америкосов, даже не могу понять, как это твиттеры у них в трубу не вылетают...