RemComm
Advanced Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
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. |
Всего записей: 839 | Зарегистр. 30-09-2003 | Отправлено: 23:18 04-04-2008 | Исправлено: RemComm, 00:13 05-04-2008 |
|
))