вопрос зачем, а главное зачем

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

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

лучше голодать в таком случае

лучше голодать в таком случае

мы в тельняшках 😄

хотя это уже пройденный этап жизни, зато не страшно жить в современной РФ после такого

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

Про железо временно можно забыть

Про железо временно можно забыть

ой да ладно, ща PIV на авито соберем =)

ой да ладно, ща PIV на авито соберем =)

Пользуясь случаем продам XEON ^_^

Говорят опенстек может менеджить вмварь...

Говорят опенстек может менеджить вмварь...

Я всё жду когда там в зелёном банке такое начнётся 😄

Говорят опенстек может менеджить вмварь...

и даже работает. Вместо клауд директора пользуют

Пользуясь случаем продам XEON ^_^

Погоди, самому пригодиться, ипотеку им закроешь

А в таком случае какие плюсы от такого подхода? 🙂

Погоди, самому пригодиться, ипотеку им закроешь

Для этого есть мак, а XEON сразу на против кремля купить квартиру 🙂

А в таком случае какие плюсы от такого подхода? 🙂

не платить лицензию за клауддиректор 😄

Для этого есть мак, а XEON сразу на против кремля купить квартиру 🙂

хорошо живете вы в своих магнитах, с размахом

не платить лицензию за клауддиректор 😄

За неё и так можно не платить с 24/02/2022

За неё и так можно не платить с 24/02/2022

это начали использовать еще до великой даты

Annemarie Ginnie: user has been CAS banned

Говорят опенстек может менеджить вмварь...

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

это начали использовать еще до великой даты

но только не все, а к кому Варя не соизволит дойти ) Т.е. мелочь всяческая )

Всем привет. Установил DevStack. Пробую подружить OS с неким стареньким модулем биллинга. Ситуация в том, что в модуль биллинга зашит URL :5000/v3/auth/tokens?nocatalog В логах модуля это выглядит так: Apr 6 06:07:24 [8705:1] libmgr TRACE Evaluate path = '/doc/processingmodule/url' Apr 6 06:07:24 [8705:1] libmgr TRACE Evaluate path = '/doc/processingmodule/login' Apr 6 06:07:24 [8705:1] libmgr TRACE Evaluate path = '/doc/processingmodule/password' Apr 6 06:07:24 [8705:1] libmgr TRACE Evaluate path = '/doc/processingmodule/domain' Apr 6 06:07:24 [8705:1] processing DEBUG openstacktools.cpp:1078 URL: 'http://10.10.84.135:5000/v3' Apr 6 06:07:24 [8705:1] processing DEBUG openstacktools.cpp:1079 Request: 'auth/tokens?nocatalog' Apr 6 06:07:24 [8705:1] processing DEBUG openstacktools.cpp:1080 Request params: '{ "auth" : { "identity" : { "methods" : [ "password" ], "password" : { "user" : { "domain" : { "name" : "Default" }, "name" : "admin", "password" : "qwerty321" } } }, "nocatalog" : true } } ' А в DevStack из коробки API Indentity доступен по адресу http://10.10.84.135/identity/v3 Block Storage http://10.10.84.135/volume/v3/53b6f255769542f48f02f45376140253 Compute http://10.10.84.135/compute/v2.1 Compute_Legacy http://10.10.84.135/compute/v2/53b6f255769542f48f02f45376140253 Identity http://10.10.84.135/identity Image http://10.10.84.135/image Network http://10.10.84.135:9696/ Placement http://10.10.84.135/placement Volumev3 http://10.10.84.135/volume/v3/53b6f255769542f48f02f45376140253 Как бы мне понять URL с http://10.10.84.135/identity на http://10.10.84.135:5000/v3/?

Хотя наверно проще изменить URL в модуле, чем в ОС так как URL http://10.10.84.135/identity похоже привязан ко всем модулям ОС

Но может перед установкой DevStack в файле local.conf достаточно будет добавить некий параметр? Сейчас у меня в local.conf: [[local|localrc]] ADMIN_PASSWORD=qwerty321 DATABASE_PASSWORD=$ADMIN_PASSWORD RABBIT_PASSWORD=$ADMIN_PASSWORD SERVICE_PASSWORD=$ADMIN_PASSWOR

Добрый день. "I'm totally new to openstack", как говорится. Помогите, пожалуйста, понять, есть ли варианты использования кластерных FS, а-ля vmfs в vSphere? Если нет, то почему? Нет достаточно стабильных и скалируемых FS (например, с GFS2 вопрос отпадает на лимите 16 нод), или, возможно, другие причины?

есть манила, которая может вам привести в вм nfs =)

Добрый день. "I'm totally new to openstack", как говорится. Помогите, пожалуйста, понять, есть ли варианты использования кластерных FS, а-ля vmfs в vSphere? Если нет, то почему? Нет достаточно стабильных и скалируемых FS (например, с GFS2 вопрос отпадает на лимите 16 нод), или, возможно, другие причины?

Вам эту кластерную ФС внутрь ВМ или под диски ВМ?

Вам эту кластерную ФС внутрь ВМ или под диски ВМ?

я имел в виду презентацию блочного устройства нескольким гипервизорам для организации общего хранилища для размещения vm

ceph ворк

ceph ворк

меня пока интересует не RAIN, а подключение вендорных массивов блоком (fc/iscsi/etc)

я имел в виду презентацию блочного устройства нескольким гипервизорам для организации общего хранилища для размещения vm

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

отвечает за это cinder (компонента опенстека) и в доке можно найти матрицу совместимости схд с циндером

меня пока интересует не RAIN, а подключение вендорных массивов блоком (fc/iscsi/etc)

Синдер вам поможет

меня пока интересует не RAIN, а подключение вендорных массивов блоком (fc/iscsi/etc)

по типу hp 3 par ?

всё отдельными драйверами рулится

https://docs.openstack.org/cinder/rocky/reference/support-matrix.html она справделива для роки, думаю можно поискать посвежее

меня пока интересует не RAIN, а подключение вендорных массивов блоком (fc/iscsi/etc)

^^^^

https://docs.openstack.org/cinder/rocky/reference/support-matrix.html она справделива для роки, думаю можно поискать посвежее

я как раз об этом: Multi-Attach Support Status: optional. Notes: Vendor drivers that report multi-attach support are able to make one volume available to multiple instances as once. It is important to note that a clustered file system that supports multi-attach functionality is required to use multi- attach functionality otherwise data corruption may occur.

реализация этой кластерной fs ведь не драйвером конкретного массива решается

для использования дисков вм не нужна кластерная фс

диски клиентские будут представлять в случае классической схд отдельно нарезанные и презентованные по iscsi луны

в случае с варью - это будет один лун, выставленный на все гиперы и поднятной поверх луна - кластерной фс, если я ничего не путаю

Да

диски клиентские будут представлять в случае классической схд отдельно нарезанные и презентованные по iscsi луны

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

в случае с варью - это будет один лун, выставленный на все гиперы и поднятной поверх луна - кластерной фс, если я ничего не путаю

всё так, я и пытаюсь понять, можно ли такое организовать в случае kvm

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

ну вот поэтому клиентские диски презентуются по другому - каждый диск - отдельный лун

и презентуется на один гипер

ну вот поэтому клиентские диски презентуются по другому - каждый диск - отдельный лун

как в таком случае отрабатывается отказ гипервизора с точки зрения файловера vm?

всё так, я и пытаюсь понять, можно ли такое организовать в случае kvm

принцип другой, результат тот же 🙂

как в таком случае отрабатывается отказ гипервизора с точки зрения файловера vm?

никак. только миграция и перезапуск

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

Возьмите cinder. У вас каждый диск будет отдельным луном который используется своей вм. Никаких проблем с конкурентностью не будет

как в таком случае отрабатывается отказ гипервизора с точки зрения файловера vm?

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

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

что не рекомендует?)

я наверное перепутал с фолт толеранс - когда два инстанса подняты?

я наверное перепутал с фолт толеранс - когда два инстанса подняты?

да, ft это совсем не ha

что не рекомендует?)

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

всем спасибо за ответы, буду дальше копать

как в таком случае отрабатывается отказ гипервизора с точки зрения файловера vm?

том на дисковом массиве будет переподключен выжевшей compute-ноде, на которой будет перезапущена ВМ

никак. только миграция и перезапуск

ну масакари может сделать nova evacuate

ну масакари может сделать nova evacuate

ну да

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

пример: vm запущена на гипервизоре 1, на vmfs томе, который презентован гиперу 1 и гиперу 2. гипер 1 отказывает, vm перезапускается на гипере 2, т.к. гипер 2 имеет доступ к общему vmfs тому. в случае опенстека, когда лун презентован только одному гипервизору, такой подход, очевидно, не работает.

ну масакари может сделать nova evacuate

вот, видимо, в эту сторону и нужно читать, спасибо

пример: vm запущена на гипервизоре 1, на vmfs томе, который презентован гиперу 1 и гиперу 2. гипер 1 отказывает, vm перезапускается на гипере 2, т.к. гипер 2 имеет доступ к общему vmfs тому. в случае опенстека, когда лун презентован только одному гипервизору, такой подход, очевидно, не работает.

работает

пример: vm запущена на гипервизоре 1, на vmfs томе, который презентован гиперу 1 и гиперу 2. гипер 1 отказывает, vm перезапускается на гипере 2, т.к. гипер 2 имеет доступ к общему vmfs тому. в случае опенстека, когда лун презентован только одному гипервизору, такой подход, очевидно, не работает.

в случае отказа гипера 1 - лун который "приаттачен" к гиперу 1 резко перепрезентуется на гипер 2 :)

в случае vmfs это один большой большой том, где куча виртуальных дисков

в случае отказа гипера 1 - лун который "приаттачен" к гиперу 1 резко перепрезентуется на гипер 2 :)

автоматику перепрезентации решает cinder?

пример: vm запущена на гипервизоре 1, на vmfs томе, который презентован гиперу 1 и гиперу 2. гипер 1 отказывает, vm перезапускается на гипере 2, т.к. гипер 2 имеет доступ к общему vmfs тому. в случае опенстека, когда лун презентован только одному гипервизору, такой подход, очевидно, не работает.

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

в случае cinder - один диск ВМ - это один том на массиве

автоматику перепрезентации решает cinder?

Нова и синдер в связке

автоматику перепрезентации решает cinder?

автоматика детекта фейлувшего гипервизора - масакари. которая стартанет процесс эвакуации вм (либо его можно вручную стартовать)

автоматику перепрезентации решает cinder?

нова + циндер, НО! если гипер ушел - автоматом никто в стоке вашу вм спасать не будет, тут нужен условно сторонний сервис типа массакари, либо ручками отправить эвакуацию

так что ХА из коробки тут нет

понял, буду в эту сторону читать, подход действительно от варного отличается

ну варя это коробка - опенстек это фреймворк =)

пример: vm запущена на гипервизоре 1, на vmfs томе, который презентован гиперу 1 и гиперу 2. гипер 1 отказывает, vm перезапускается на гипере 2, т.к. гипер 2 имеет доступ к общему vmfs тому. в случае опенстека, когда лун презентован только одному гипервизору, такой подход, очевидно, не работает.

cinder драйвер и у вас каждого volume созданного openstack будет нарезан отдельный маленький лун. Лучше посмотрите конкретную реализацию драйвера cinder для массива, который вы используете, некоторый вопросы сразу отпадут) https://github.com/openstack/cinder/tree/master/cinder/volume/drivers

так что ХА из коробки тут нет

А нужен ли. Когда же облака уже станут облаками. Умерла вм да и х с ней

А нужен ли. Когда же облака уже станут облаками. Умерла вм да и х с ней

ну клиенты вари чаще всего не совсем умеют именно в облака, да и српаведливости ради много софта обычного ентерпрайзного не умеет в ха на уровне софта

ну клиенты вари чаще всего не совсем умеют именно в облака, да и српаведливости ради много софта обычного ентерпрайзного не умеет в ха на уровне софта

Именно так, не всегда клауд нэйтив имеет место быть

А нужен ли. Когда же облака уже станут облаками. Умерла вм да и х с ней

когда все будет в кубере и не нужен будет openstack

когда все будет в кубере и не нужен будет openstack

я это уже последние лет 5 точно слышу

когда все будет в кубере и не нужен будет openstack

скорее бы