цитата:
все про все в день бэкапить от силы 80-100Гиг
бэкапы бэкапам рознь, если действительно все так радужно с 20тир предполагаемой загрузки, то очень даже хорошо)
цитата:
Или старая добрая ленточка?
то было давно, рентабельность нынче другая
Блейд форм-фактор тупиковое направление. Имхо.
Основные проблемы:
1. Вы не можете вмешаться в мид-плейн, т.е. вся коммутация от коммутаторов (IO-модулей в шасси) или path-thru модулей до лезвий вам не доступна, и когда возникает непонятная ситуация - сложно диагностировать.
2. Невозможность увеличения количества IO-портов на самиих лезвиях (FC или Ethernet). Иногда бывает нужно иметь больше чем 2 интерфейса, дабы разграничить дата-трафик от того же vMotion или Management. А бывает необходимость еще и осуществлять балансировку дата-трафика.
3. Высоконагруженные дата-центры не используют блейд форм-факторы. К примеру тот же фейсбук
Им проще использовать свой форм-фактор, но не блейд. Т.к. более гибче получается серверная инфраструктура.Так же есть серьезные ограничения в ассортименте интерфейсных модулей, которые возможно установить в шасси (например Ethernet или FC). Эта ограниченность серьезно влияет на формирование сетевого едионообразия в сети ЦОД. К примеру Вы решили, что Вам в вашем цоде просто необходимо организовать Ethernet-фабрику, но полноценно подключить серверы "напрямую" к фабирке Вы не сможете, т.к. у вас так или иначе должен быть IO-модуль в шасси (пусть даже path-thru), который маловероятно сможет интегрироваться в Exthernet-фабрику (TRILL или SPB). Что в свою очередь ведет к гетерогенности среды, которая может вылиться в непредсказуемые проблемы.
Поэтому мое мнение, если хочется гибкости и возможности развития - не надо шассийности. Именно поэтому большинство производителей, к примеру сетевого оборудования, направили свои силы не на развитие огромных директоров для ЦОД, а на обычные (в плане форм-фактора) 1-2 юнитовые коммутаторы (те же Cisco Nexus, никто даже и не решиться ставить Cisco 6000 в цод, ибо геморой).
Имхо.
Так же имея корзину вы потенциально имеете единую точку отказа.
При выходе из строя платы или нескольких плат бек-плейна и более 10 серверов (физических!) у вас становятся недоступны на неопределенный срок (от 1 дня до нескольких недель).
Если смотреть на СХД - то признанный лидер тут конечно ЕМС
Какой нибудь VNX2 вам вполне подойдет. VNX5200 или VNX5400.
Но это достаточно не дешего.
Для выбора СХД необходимо понимание не только объема, но и нагрузки, которая будет ложиться на данную СХД.
Deks против ИМХО не попрешь, но через-чур ты сильно пугаешь, в настоящее время консолидировать десятки разнородных серверов можно только на блейде, и пока плюсы на порядок превышают минусы.
А плюсы та в чем? Кроме консолидации управления?
И что ты вкладываешь в понятие консолидации разнородных серверов?
На сегодняшний день, все компании так или иначе стараются виртуализировать все свои сервера. Виртуализация дает ту самую консолидацию. И ей не важно в шасси у тебя стоят серверы или они стоечные.
Единственный плюс шасси - это единая точка управления (но и точка отказа).
Однако у нас вся информация о состоянии железа на серверах доступна и в vCenter (если говорить о VMWare).
Централизованное управление: как часто нам нужно иметь доступ к консоли сразу нескольких серверов (консоли гипервизора) из одного окошка? Думаю не часто (на этапе установки/переустановки гипервизора).
По мне - я плюсов не вижу. Тупиковый вариант для динамично-развивающейся инфраструктуры.
К тому же, чтобы мониторить состояние серверов не нужно каждый раз лезть на каждый сервер - для этого есть разного рода системы мониторинга.
PS: мне тоже нравились блейд-сервера, однако столкнувшись с несколькими неприятными ограничениями, понимаешь, что это не совсем то что хочется.
цитата:
Изначально написано Deks:
А плюсы та в чем? Кроме консолидации управления?
Очень много, перечислять это целую статью ваять, возьмем хотя-бы основные:
- Однородность базовой среды во всех отношениях, начиная от физической конфигурации заканчивая средой виртуализации;
- Экономичность, начиная от банального энергопотребления заканчивая затратами на обслуживание;
- Надежность, что-бы Вы не говорили о существовании единой точки отказа, но кажется что Вы забыли о банальном резервировании.
Вы говорите о
цитата:А как-же система прогнозирование неисправностей, а как-же миграция при наличии избыточного объема ресурсов, а как-же банальная расширенная техподдержка 24х7х4, и так далле. Но как говорится "под лежачий камень вода не течет".
Изначально написано Deks:
При выходе из строя платы или нескольких плат бек-плейна и более 10 серверов (физических!) у вас становятся недоступны на неопределенный срок (от 1 дня до нескольких недель).
цитата:
Изначально написано Deks:
И что ты вкладываешь в понятие консолидации разнородных серверов?
Да возьмем например какой-нить MS SQL сервер на конфигурации 2xCPU/64 Gb и обычный древний прокси на каком-нитьADM/2Gb, и перенесем их в виртуальную среду, как это будет называться ?
p.s. И вообще каждый случай должен иметь свой подход, решение по шаблонам это ...
цитата:
Однородность базовой среды
Однородность базовой среды не обязательно можно достигнуть блейдом: приобретая одинаковые сервера получаем ту же самую однородность.
цитата:
Экономичность, начиная от банального энергопотребления
С энергопотреблением спорить не буду. но давайте на чистоту - где у нас в Ижевске хоть раз люди задумывались, что вот шасси с 14 нодами будем потреблять максимум 5кВТ, а те же 14 стоечных серверов - 8кВт. И то это пиковые показатели, достигнуть которых вряд ли удастся.
цитата:
Надежность
Банальное резервирование есть и у стоечных серверов.
Однако давайте вспомним математику. Вероятность отказа в какой системе больше? Там где цепочка зависимостей большая или маленькая?
К примеру:
вероятность отказа материки на сервере одинаково и для блейда и для стоечного
вероятность отказа сетевого интерфейса так же одинакова
однако движемся дальше: у шасси есть мид-плейн или по-просту говоря внутришасийная коммутация. У стоечных этого нет. Т.е. появляется вероятность выхода из строя этого элемента, от которого, на минуточку, зависят ВСЕ! лезвия в шасси.
Пусть у него есть резервирование. Однако этот элемент есть и не стоит им пренебрегать.
В итоге общая вероятность выхода из строя блейд-севрера выше чем стоечного.
При этом есть вероятность выхода из строя вообще всех серверов. У стоечных такой проблемы нет.
С математикой сложно спорить.
Шанс выхода из строя внешней коммутации так же одинаков.
цитата:
система прогнозирование неисправностей
Система прогнозирования неисправностей присутствует и у стоечных серверов (конечно я говорю о вендорных серверах: IMM и IPMI интерфейсы никто не отменял). Так же как и поддержка у них такая же 24х7х4.
цитата:
Да возьмем например какой-нить MS SQL сервер на конфигурации 2xCPU/64 Gb и обычный древний прокси на каком-нитьADM/2Gb, и перенесем их в виртуальную среду, как это будет называться ?
А что в этом такого?
Вас же не удивляет соседство разных гостевых ОС на одном гипервизоре.
Спор переходит в фазу обсуждения генотипа сферического коня в вакууме.