Без виртуализации, о которой пойдет речь в следующей части — да. В такой сервер, как описан в статье можно установить до 3 карт, итого до 12 машин на сервер — для «тяжелых» машин, которые и других ресурсов много потребляют, и двухсокетного сервера — нормальный уровень нагрузки.
VMware умеет обеспечивать целостность данных в VM средствами vmware tools quiescence, реально это работает в windows для VSS-aware приложений. В принципе могут сущестовать агенты на уровне приложения, взаимодействующие с vmware tools, либо можно написать необходимые скрипты. Если этого не делать — то в результате будет получена reset-consistent копия; сохранится ли в таком случае целостность БД — вопрос к ее структуре и внутренним механизмам обеспечения целостности.
Обратная репликация, как впрочем и первоначальная прямая, может быть произведена с использованием seed дисков, заранее скопированных в offline (или сохранившихся на основной площадке). В таком случае на обеих сторонах будут пересчитаны контрольные суммы дисков и переданы только измененнные данные. Это быстрее полной репликации, хотя и медленнее пересылки заведомо известных дельт, как в случае с регулярной синхронизацией.
Для данного конкретного проекта использовалась общая инфраструктура (безусловно, с ограничением прав на уровне объектов vSphere, не объектов Replication). Т.к. сам Replication не имеет эффективной системы разграничения прав, для дальнейших проектов у нас прорабатываются различные варианты, как выделенные физические инфратруктуры, так и возможность использования nested virtualization (хотя прибегать к такому варианту конечно-же не хочется — не многих заказчиков это устроит)
При использовании vSphere Replication никаких автоматических действий не производится, и после recovery VM администратору необходимо войти на машину, назначить новую портгруппу, при необходимости (если меняется ip адресация, в данном проекте — не меняется) — назначить новый ip адрес. В случае использования SRM эти действия (назначение портгруппы, адресов и т.п.) выполняет сам SRM при failover-е (автоматическом или инициированном администратором)
Перечитал статью, возможно имеет смысл упомянуть и про MS System Center, на ряду с продуктами VMware vCloud Automation Center или Cisco Cloupia. MS System Center тоже это умеет, а MS игрок на рынке не самый маленький.
И кстати, руление блейдами путем предварительно заданных политик отнюдь не ограничивается рамками одного шасси (хотя все примеры в документации действительно за рамки одного шасси не выходят), а шасси к паре Fabric Interconnect можно подключить под пару десятков (зависит от ширины агрегированных каналов шасси<->FI). Человек который привык рулить отдельными физическими серверами (как следствие – несколько зашоренный во взглядах) сам о подобном не задумается и не ощутит всю мощь решения Cisco.
С выходом UCSM 2.1 поддерживается multi-hop, что дало возможность осуществления взаимодействия массива и серверов по FCoE без перехода на Ethernet или FC.
Приведенные выше ссылки и выписки к микросерверу habrahabr.ru/company/hp/blog/132733/ отношения не имеют.
Если говорить о C7000, то это прекрасное решение. И HP этим пользуется. Но и у него есть много ограничений. Какие-то критичны, какие-то нет. Все зависит от задачи. Любое решение не идеально. Повторюсь, создание супера — это отдавливание не одной мозоли на любимых пальцах.
1. Не во всех представленных решениях присутствуют перечисленные вами девайсы. Но заметка в тему. В блейдах сложно встретить одновременно все самые эффективные компоненты из вашего списка. Естественно, что любой суперкомпьютер получается сборищем компромиссов.
2. Перечислите виды мезонинных модулей. Сравните их характеристики с аналогичными платами PCI-e. Добавьте ограничения по количеству портов встраиваемых коммутаторов. Возможность установки специализированных плат в нужном количестве… Разве это не ограничения?
3. А отлаживать и ремонтировать как?
4. А вы пробовали иметь следующие интерфейсы сразу в одном шасси: FC, 10GbE, Infiniband? И это далеко не весь список возможных желаний конструктора HPC.
5. Большинство встраиваемых коммутаторов имеют больше портов внутрь, чем наружу. Все лезвия одновременно пойти во вне не могут.
6. Пожалуйста, поподробнее. В каком решении и какой плотности это возможно? Водянку не берем — слишком специфична.
7. Но всё же это минус :-)
8. Если стандартные ЦОД’ы задумываются на мощность 6-10кВт, то высокоплотные решения могут потребовать и 50кВт. Да, они адекватные, но все же повышенные относительно привычных требований.
Это решение для HPC я бы использовать не стал бы. Даже если не брать во внимание отсутствие поддержки Infiniband, в данном решении слишком много вопросов. Например:
— 3 канала на сокет при возможности CPU иметь 4 канала.
— Невозможность организации толстого дерева для FC и 10GbE (кроме NX226, да и то в HPC это очень узко можно использовать).
— Процессоры E5-4600 достаточно горячие. Плотность очень высокая. Установить туда процы с разумной производительностью невозможно. Это офисно-облачный вариант для экзотики.
Интересный пример микросерверов. Правда код x86-x64 эти сервера никогда не поймут. :-(
Да и сеть сильно потеснит их в шкафу (реально сейчас доступны около 64 порта на 1U). Нереалистичные маркетинговые данные.
Вопрос конструктивного исполнения серверов для получения каких-либо дополнительных возможностей (в вашем случае выдергивания CPU на «горячую») интересен сам по себе. Но, скажите, пожалуйста, Вы будете дёргать CPU во время боевого режима? Я при любых раскладах буду выполнять работы с целой вычислительной нодой, отключив её от кластера и обесточив.
Для примера, вспомните прекраснейшую компанию DEC. До сих пор её новаторские идеи баламутят компьютерный мир. Они первые, кто в серверах x86 применили горячую замену PCI-карточек. Кто-то реально этим воспользовался? Но в требованиях на тендер это прописывали.
Что касается элементов надёжности, то наверное IBM серьёзней всех подходит к вопросу. Но и они начали отказываться от дублирования в Blade-решениях. Мы сможем предложить альтернативный вариант решения на базе Dell, но прошу дать время до завтра на подготовку. Оставьте свой емейл в личке.
Кто из производителей занимается FC? Это Brocade, QLogic, Emulex, CISCO. Эти же компании делают мезонинные модули по заказу и форм-фактору компаний, выпускающих сервера. Совместимы они с теми же вендорами, но по спецификации производителя серверов. Чудес, как Вы правильно выразились, не бывает.
Модули дорогие. Производителям делать их накладно. Из-за пары тройки модулей связываться обычно не желают. Это правда :-(. Поэтому надо покупать сразу много таких платформ и к ним партию модулей :-). На самом деле, купить такие модули можно. Исходя из Вашего опыта – не у всех они могут быть. Просто не повезло. Не напали на нужную компанию.
Да, в T-Blade-2 32 2-х процессорных сервера, но посмотрите на ограничения. Что действительно там классно, так это отдельный управляющий модуль (развитая идея ИПС РАН). Если говорить формально, то, конечно, у Т-Платформ что-то сделано. Но надо также смотреть и на архитектуру решения и на ее распространённость. Если рассматривать альтернативные решения, то необходимо говорить и о Cray, и о IBM, и о SGI… Можно поговорить и о спецрешении для интернет-компаний. В России такие технологии применены, например, в Yandex’е. Там плотность ещё выше. В рамках этого же поста предлагаю остановиться на общедоступных решениях, производители которых обеспечивают мировую гарантию.
Задавая эти вопросы, Вы уходите несколько в другую область. Это эффективность процессоров, архитектуры MB, архитектуры и комплектации вычислительной нолы, архитектуры кластера и применённых технологий в его реализации. Это так сильно перевязано, что надо копать слишком глубоко и дна всё равно не достать без сборки двух стендов и выработки методики испытаний. Это сделать практически невозможно из-за необходимости привлечения ресурсов, занятых добыванием хлеба насущного. Поэтому оставим Этот вопрос без однозначного ответа. Могу сказать только одно, всё зависит от Задачи. И вряд ли все компоненты возможного решения резиново бесконечны :-).
Обратная репликация, как впрочем и первоначальная прямая, может быть произведена с использованием seed дисков, заранее скопированных в offline (или сохранившихся на основной площадке). В таком случае на обеих сторонах будут пересчитаны контрольные суммы дисков и переданы только измененнные данные. Это быстрее полной репликации, хотя и медленнее пересылки заведомо известных дельт, как в случае с регулярной синхронизацией.
И кстати, руление блейдами путем предварительно заданных политик отнюдь не ограничивается рамками одного шасси (хотя все примеры в документации действительно за рамки одного шасси не выходят), а шасси к паре Fabric Interconnect можно подключить под пару десятков (зависит от ширины агрегированных каналов шасси<->FI). Человек который привык рулить отдельными физическими серверами (как следствие – несколько зашоренный во взглядах) сам о подобном не задумается и не ощутит всю мощь решения Cisco.
Если говорить о C7000, то это прекрасное решение. И HP этим пользуется. Но и у него есть много ограничений. Какие-то критичны, какие-то нет. Все зависит от задачи. Любое решение не идеально. Повторюсь, создание супера — это отдавливание не одной мозоли на любимых пальцах.
2. Перечислите виды мезонинных модулей. Сравните их характеристики с аналогичными платами PCI-e. Добавьте ограничения по количеству портов встраиваемых коммутаторов. Возможность установки специализированных плат в нужном количестве… Разве это не ограничения?
3. А отлаживать и ремонтировать как?
4. А вы пробовали иметь следующие интерфейсы сразу в одном шасси: FC, 10GbE, Infiniband? И это далеко не весь список возможных желаний конструктора HPC.
5. Большинство встраиваемых коммутаторов имеют больше портов внутрь, чем наружу. Все лезвия одновременно пойти во вне не могут.
6. Пожалуйста, поподробнее. В каком решении и какой плотности это возможно? Водянку не берем — слишком специфична.
7. Но всё же это минус :-)
8. Если стандартные ЦОД’ы задумываются на мощность 6-10кВт, то высокоплотные решения могут потребовать и 50кВт. Да, они адекватные, но все же повышенные относительно привычных требований.
— 3 канала на сокет при возможности CPU иметь 4 канала.
— Невозможность организации толстого дерева для FC и 10GbE (кроме NX226, да и то в HPC это очень узко можно использовать).
— Процессоры E5-4600 достаточно горячие. Плотность очень высокая. Установить туда процы с разумной производительностью невозможно. Это офисно-облачный вариант для экзотики.
Да и сеть сильно потеснит их в шкафу (реально сейчас доступны около 64 порта на 1U). Нереалистичные маркетинговые данные.
Для примера, вспомните прекраснейшую компанию DEC. До сих пор её новаторские идеи баламутят компьютерный мир. Они первые, кто в серверах x86 применили горячую замену PCI-карточек. Кто-то реально этим воспользовался? Но в требованиях на тендер это прописывали.
Что касается элементов надёжности, то наверное IBM серьёзней всех подходит к вопросу. Но и они начали отказываться от дублирования в Blade-решениях. Мы сможем предложить альтернативный вариант решения на базе Dell, но прошу дать время до завтра на подготовку. Оставьте свой емейл в личке.
Кто из производителей занимается FC? Это Brocade, QLogic, Emulex, CISCO. Эти же компании делают мезонинные модули по заказу и форм-фактору компаний, выпускающих сервера. Совместимы они с теми же вендорами, но по спецификации производителя серверов. Чудес, как Вы правильно выразились, не бывает.