» VMware ESX Server и VMware Infrastructure

Remzy
windows Unified Data Storage и по iSCSI каждому серверу отдельний диск

Цитата:

Remzy
windows Unified Data Storage и по iSCSI каждому серверу отдельний диск

иСкази это вариант по сети, но зачем мне сетевое решение, если у меня ФИБРА черел - оптическое подключение к стораджу.
Наверняка как-то можно сделать прямое подключение к диску виртуальных машин с единовременным использованием ресурсов.

иСКАЗИ в данном случа это последнее дело.. или просто нарезать много виртуальных дисков, что КРАЙНЕ НЕ грамотно

Michigun
Спасибо за подробное разъяснение !
Вроде все понятно.

Но возникла другая проблема, был ESX 3i загружаемый с флэшки. Под ним были созданы несколько ВМ на дисковом массиве SAS. ФС - VMFS.

Загружаю ESX 3i с другой флэшки. Он видит видит только два storage из четырех.
Остальные два можно добавить. Но созданные ранее ВМ размещены на одном из этих storage. При попытке добавить (Через VIC -Add storages) говорит, что все данные на нем будут потерены.

Почему ESX изначально не видит storage с ВМ и как заставить их увидить ?

Remzy

Два варианта есть. Использовать виртуализированную СХД с т.н. опцией Thin Provisioning, когда виртуальный "диск" занимает на физических носителях лишь столько места сколько ОСь запросила (на уровне блоков данных). Но это сложный путь.

Простой путь - использовать почти любую shared file system, а не NTFS, т.к. NTFS не позволяет одновременный прямой доступ нескольких ОС к одной файловой системе.

Например MelioFS.

Но я не уверен, что MelioFS - это достаточно надежное решение, когда речь идет о сторадже для баз данных.

Barma7483

Цитата:

Два варианта есть. Использовать виртуализированную СХД с т.н. опцией Thin Provisioning, когда виртуальный "диск" занимает на физических носителях лишь столько места сколько ОСь запросила (на уровне блоков данных). Но это сложный путь.

Это не вариант. Система почти работает, диск подключается. Вопрос именно как сделать. Тем более функция есть, но как заставить работать правильно.
Несколько серверов физических видят единый диск и это корректно даже на карте отображается. Но как подключить к ОС

Remzy
это не возможно. потому что когда до сервера подключаться физический диск то он работает на уровне блоков данных, если мы используем файловую шару то тогда на уровне ФС. если диск raw и его используют одновременно 2 сервера то кто разруливает ситуацию кому куда писать и что читать на уровне блоков? Для таких ситуаций нужно софт типа MelioFS, MetaSan но это как то не правильно делать в vmware.
Чем не подходит вариант сделать отдельный диск каждому серверу?

funtopgun

Цитата:

это не возможно. потому что когда до сервера подключаться физический диск то он работает на уровне блоков данных, если мы используем файловую шару то тогда на уровне ФС. если диск raw и его используют одновременно 2 сервера то кто разруливает ситуацию кому куда писать и что читать на уровне блоков? Для таких ситуаций нужно софт типа MelioFS, MetaSan но это как то не правильно делать в vmware.
Чем не подходит вариант сделать отдельный диск каждому серверу?

ГЫ,...
так для этого и есть специальный фибра сторадж с навороченным контроллером, который может выдавать диск нескольким серверам и ОС сразу
ESX сервер же принимает же... но там линух...
а тут винды... как-то ЕСХ должен это передавать

Remzy

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

Вопрос! Откуда по-вашему другой (второй) сервер будет знать какие изменения на диске сделал первый сервер? чтобы например не затереть данные записанные ранее другим сервером...?

Вот для того, чтобы он (второй сервер) знал, что сделал первый сервер, и придуманы shared file systems (или cluster file systems). Их множество. Обмениваются данными такие FS, установленные на разных серверах, обычно по простому ethernet.

ESX сервер умеет юзать единый сторадж именно потому-что на нем используется VMFS. Это и есть cluster/shared file system... её брат-близнец в RedHat - GFS.

Ну, короче говоря, википедия ответит на все вопросы

http://en.wikipedia.org/wiki/SAN_file_system

Проблема с потерей storages кажется решена

Цитата:

ГЫ,...
так для этого и есть специальный фибра сторадж с навороченным контроллером, который может выдавать диск нескольким серверам и ОС сразу
ESX сервер же принимает же... но там линух...
а тут винды... как-то ЕСХ должен это передавать

ты пожалуйста не путай.
ESX все, что надо передает. А вот твои гостевые ОС, имено операционные системы, не умеют работать в нужном тебе режиме. Если ты безо всяких ВМ дашь с СХД один LUN нескольким хостам, увидишь ту же картинку.

Barma7483
+1

Remzy
для примера раздай iSCSI сторедж двум серверам и увидишь что два компьютера одновременно писать и читать не смогут на один диск, потому что нужна определенная ФС. Можно еще почитать здесь на эту тему http://3nity.ru/
И у меня вопрос почему “или просто нарезать много виртуальных дисков, что КРАЙНЕ НЕ грамотно” не грамотно??? Это может на сайте vmware написано, или такое решение кажется вам не красивым???

Цитата:

ты пожалуйста не путай.
ESX все, что надо передает. А вот твои гостевые ОС, имено операционные системы, не умеют работать в нужном тебе режиме. Если ты безо всяких ВМ дашь с СХД один LUN нескольким хостам, увидишь ту же картинку.

Так я так и выдал LUNём один диск нескольким физическим серверам, а там их выдал для OS
Т.е. получается так, что ESX может видеть единый диски разместить там виртуальные диски, что б их выдать конкретной ОС. Один виртуальный диск на одну машину. И никак иначе, если не использовать айСКАЗИ или шаринг какой. ТАК?

Remzy
VMWare имеет свою cluster File system - VMFS и поэтому несколько хостов ESX одновременно могут видеть один LUN и работать с ним, это необходимая вещь для HA и DRS. Соответственно один виртуальный диск на одну машину, или внутри VMFS делать еще одну кластерную файловую систему, но надстройка над настройкой может привести к падению производительности

Цитата:

Так я так и выдал LUNём один диск нескольким физическим серверам, а там их выдал для OS
Т.е. получается так, что ESX может видеть единый диски разместить там виртуальные диски, что б их выдать конкретной ОС. Один виртуальный диск на одну машину. И никак иначе, если не использовать айСКАЗИ или шаринг какой. ТАК?

Вот смотри:
у тебя есть LUN на СХД.
что с ним сделать? два варианта:
1) сделать на нем VMFS. Тогда с этим LUN работают ESX'ы, на нем лежат файлы vmdk - фалы диски ВМ. Один диск для одной ВМ.
2) сделать RDM, Raw Device Mapping. В этом случае этот LUN отдается как диск ВМ. Т.е. почти тоже самое, как если бы у тебя винда стояла на физическом сервере, подключеном к SAN, и ты LUN с SAN tq отдал.

по варианту 2 ты сделать можешь. НО! сама винда не сможет нормально работать, если ты один LUN отдашь как RDM нескольким ВМ. Т.е. с т. зрения ESX все сделано как ты и хотел, проблема на уровне гостевой ОС.

Michigun

Цитата:

2) сделать RDM, Raw Device Mapping. В этом случае этот LUN отдается как диск ВМ. Т.е. почти тоже самое, как если бы у тебя винда стояла на физическом сервере, подключеном к SAN, и ты LUN с SAN tq отдал.

по варианту 2 ты сделать можешь. НО! сама винда не сможет нормально работать, если ты один LUN отдашь как RDM нескольким ВМ. Т.е. с т. зрения ESX все сделано как ты и хотел, проблема на уровне гостевой ОС.

Первый вариант я делал и всё понятно и однозначно, но не корректное распределения пространства не даёт мне спать

второй вариант я делал, но как и сказано, имеются проблемы с гостевой ОС, и вопрос, как это исправить, как заставить их видеть. Может плагин какой есть для ОС под такое решение.

Вот что мне на ОФФ форуме ответили...

You can't do this without addition software on the host OS. If a disc is shared between hosts you need some method of arbitrating which host 'masters' the disc at any time since two hosts writing to the same disc will corrupt it. A good example of this is Microsoft Cluster Services (MSCS).

этот "плагин" и есть некая shared/cluster file system, коих множество под разные ОСи.

почти все кластерные файловые системы - платные.

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

Ага! Вот вы где тусуетесь!

Barma7483

Цитата:

этот "плагин" и есть некая shared/cluster file system, коих множество под разные ОСи.

А можно поподробнее, мелкий/мягкий кластер вроде не поддерживает shared/cluster file system, только НТФС, и соответственно только одна нода владеет диском (в определенный момент времени).
мелкий/мягкий кластер это т.н.з. фаил-овер кластер, не актив-актив.
А что нужно поставить (shared/cluster file system?), чтобы мелкий/мягкий кластер стал актив-актив?
Я похоже опять офф-топик написал…
А куда ж это еще писать?

Apokrif

Это более к вопросам о функциональности винды. Но не будет флеймом внести некоторую ясность.

Если обратиться к фундаментальным первоисточникам от MS, то там есть раздел, описывающий кластерную реализацию от Микрософта. Склероз изменяет мне уже в значительной степени, поэтому дословно не приведу, но суть в том, что кластер с общим дисковым хранилищем не поддерживает схему Active - Active. Эту схему поддерживают только кластера NLB, которым общее хранилище не нужно. Причина именно в отсутствии своей CFS. Сужествуют сторонние решения именно под MS, одеспечивающие CIO (concurent IO) на общем дисковом хранилище, но такие решения не считаются кластерными с позиции MS. К тому же эти решения не получили распространения. Соответственно, вопросы их сертификации, надежности, остаются открытыми. Плюс вопросы стоимости никто не отменял увы. Если в таком решении возникает необходимость, то стоит обратить свой взор в области ... мм... скажем... System P + GPFS от IBM (пришло в голову сразу ибо пользую)... Или решение от Санок... Или нечто аналогичное... Если речь идет об Oracle, то есть Oracle CFS... Но никак не малой кровью...

Remzy все сделал правильно с позиции VI, но уперся в функциональное ограничение гостя, о котором написал выше. В свое время я так же был озабочен пободной проблемой и решал ее следующим образом:

имеем SAN Storage (в моем случае DS4800), который шарим (если в этом есть нужда, не ключевой момент) между хостами ESX. На нем VMFS. Единое дисковое пространство для всех гостей. Ключевой момент - все доступное пространство не разбивается сразу, а каждому гостю выделяется только необходимое количество места в виде thick vmdk (обьем, который вполне достоверно можно определить при помощи методов планирования), которые увеличиваются по мере необходимости. А после увеличения виртуального диска, в госте, соответсвенно, растягивается файлуха. Ну да, минус в том, что надо что-то делать руками. Тем не менее - вполне работоспособно, ну и напильник никто не отменял. А ежели речь идет о решениях 999.9(24/7) - то это не винда и не линух и не x86/x64.

Добавлено:
И раз уж разговор пошел в таком ключе, то позвольте пару слов о ГРАМОТНОСТИ и ВЫСОКОНАГРУЖЕННЫХ системах... VI - это в первую очередь консолидационное решение, призванное избавить от кучи мелкого железного хлама, коим сплошь и рядом забиты серверные, и упорядочить аппаратную инфраструктуру. Но никак не для выжимания большего количества лошадей "на горшок" путем сокращения их (горшков) количества (пересчет тактовой частоты процессора на ядро в ракурсе "общего количества гигагерц" - есть ересь). Предел VI - 4 vCPU на узел. Это - не высоконагруженная система (хотя тут множество суждений допустимо). Не совсем реализуемо в пределах возможностей VI.

Актуальна ли для ESX 3.5 эта рекомендация отключать PAE в гостях?

Обнаружил "Расширение физических адресов" на виртуализованном терминальнике (2003 Ent R2, 3572М памяти) последней строчкой в "сведениях о системе". Добавление в boot.ini ключа /nopae эту хрень не отключает.

LevT
на сайте vmware:
"Disable PAE in ESX Server Virtual Machines
ESX Server 2.5.x: Although ESX Server 2.5.x virtual machines are compatible with Physical Address Extension (PAE), they are not optimized for it. As a result, guest operating systems with PAE enabled might experience poor performance. For best performance, VMware recommends that you disable PAE in guest operating systems. For more information and instructions on disabling PAE, see the knowledge base article at kb.vmware.com/kb/2020.
ESX Server 3.x: Note that disabling PAE also disables NX (no execute) and ED (execute disabled) features found in recent AMD and Intel processors. These features are not supported by ESX Server versions before ESX Server 3.x."

Добавлено:
LevT
И относительно производительности интересный документик
http://www.vmware.com/files/pdf/large_pg_performance.pdf

funtopgun
первое я читал. За ссылку по-любому спасибо - но это точно про РАЕ? И как все-таки эту PAE отключить? Не нравится мне, что винда ключа в бут.ини не слушает...

LevT
Разве вы используете версию ниже 3.х? На микрософте читал где-то что финда имеет некий механизм, который позволяет ей самостоятельно принимать решение о включени PAE. Вроде как если памяти больше 4 Gb, то на 32 битных виндах PAE всегда включен иначе до памяти не достучаться...

RemComm
версия у меня ESX 3.5. Мне кажется, что статья в pdf по ссылке не о pae. Я неправ?

Посмотрел: у меня pae включено по крайней мере в двух 32-битных гостевых терминальниках -с 3.5 и 2 гектара памяти соответственно. Я его не включал. Как вырубить?

LevT

Вы абсолютно правы, но мой пост относился к
Цитата:

Актуальна ли для ESX 3.5 эта рекомендация отключать PAE в гостях?

Обнаружил "Расширение физических адресов" на виртуализованном терминальнике (2003 Ent R2, 3572М памяти) последней строчкой в "сведениях о системе". Добавление в boot.ini ключа /nopae эту хрень не отключает.

RemComm
честно говоря, я не понимаю, в чём я прав и мне не столько правота нужна, сколько разрешение непоняток. Например, где-то написано, что та рекомендация НЕ относится к 3? Или кто-то здесь может утверждать это на личном опыте? Также - слегка офтоп - был бы признателен за наводку на объяснение причин, из-за которых пае в гостевой винде не отключается.

насчет как выключить... Например, Microsoft утверждает, что:


Цитата:

The PAE kernel can be enabled automatically without the /PAE switch present in the boot entry if the system has DEP enabled (/NOEXECUTE switch is present) or the system processor supports hardware-enforced DEP. Presence of the /NOEXECUTE switch on a system with a processor that supports hardware-enforced DEP implies the /PAE switch. If the system processor is capable of hardware-enforced DEP and the /NOEXECUTE switch is not present in the boot entry, Windows assumes /NOEXECUTE=optin by default and enables PAE mode. For more information, see the topic "Boot Options in a Boot.ini File" in the Windows DDK.

/nopae - этот ключ актуален только для XP. Вам надо пользовать ключ /execute, как описано вот, например, тут.



Добавлено:

Цитата:

Например, где-то написано, что та рекомендация НЕ относится к 3?

Конечно. на этой же странице:

Цитата:

ESX Server 3.x: Note that disabling PAE also disables NX (no execute) and ED (execute disabled) features found in recent AMD and Intel processors. These features are not supported by ESX Server versions before ESX Server 3.x.

Именно по этой причине его и надо было дисейбл в предыдущих версиях.

Цитата:

Или кто-то здесь может утверждать это на личном опыте?

Конечно. Я могу. Ведь у меня тоже енвармент под ESX-ом.

Спасибо!

Какие решения объединения дискового пространства вы можете посоветовать? Какая программа может помочь в предоставления одного физического диска нескольким виртуальным гостевым системам? При этом хочется получить высокую дисковую производительность.

Это к вопросу к один диск на несколько ОС...
Есть разные программные решения этого на уровне гостевой ОС.. кто какие использовал? Какой опыт? Какое решение лучшее?

Remzy

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

Ни о каком шаринге общего логического диска средствами кластерных файловых систем при использовании баз данных речи быть не может.

Barma7483

Цитата:

Ни о каком шаринге общего логического диска средствами кластерных файловых систем при использовании баз данных речи быть не может.

Из чего это следует? Некоторые схемы организации напротив категорически требуют кластерную ФС - да тот же RAC. И для этих целей как раз и придуманы GPFS или OCFS... Другое дело, что Remzy желает использовать эти механизмы не по их прямому назначению.

Исходя из предоставленной Remzy информации: ESX + Win + сиквел - речь не идет высокой производительности. Вот тут как раз ни о каком RDM речь идти и не может. Не умеет винда с сиквелом данные на сырых томах размещать. Посему можно говорить о например тех же MelioFS или MetaSAN. Есть у меня правда сомнения что эти технологии будут работать на SCSI - надо пробовать. Им надо FC, а VI не предоставляет гостю такого типа устройств.