Pull to refresh

Comments 19

Смотел вчера на эту железячку и как то не смог найти
1) Как делается горячая замена дискам?
2) Как используется лезвие с дисками? Типа на оставшиеся лезвия можно расшарить доступ к лунам или как?
1) Так увлёклись облачным словоблудием, что забыли про главное — вопросы по самому продукту.
Итак, горячая замена в модуле хранения C8220XD реализуется выдвижением корпуса с дисками из оболочки модуля с сохранением коммутации и питания. Т.е. сам C8220XD представляет из себя мини-шасси, из которого можно выдвинуть сам корпус с дисками без их отключения. Лучше увидеть на тюбе

Также есть возможность горячей замены в модуле C8220X в версии без поддержки GPGPU. В статье опечатка. В C8220X горячая замена есть у двух дисков (с морды доступных), остальные без горяей, но с быстрой доступностью без инструментов.

2) на модуле C8220XD есть 4 порта SAS (2 порта с двух экспандеров) и через них можно подключать остальные модули C8220X и C8220 с установленными мезанинами LSI.
Но что делать «обычному» облаку, когда этот клиент уйдёт, а на его место придёт другой

Заказчикам из ЦОДов, как это ни парадоксально, всегда гораздо проще купить standalone сервер 1U-2U под плавающие задачи, в пересчете на доллары это выйдет гораздо дешевле, как по энергоэффективности, так и по тепловыделению.
Похожие решения доступны уже несколько лет, например, HP s6500, но их эффективно применять в больших HPC-проектах, чтобы получить высокую плотность на U (~160 процессоров на стойку).
По нашему опыту в РФ и в целом опыту Dell DCS в мире 1-2U системы в многоузловых окружениях уступают место специализирвоанным системам, т.к. изначально проектировались больше как standalone. Вышеуказанная HP SL, а также многие модели SuperMicro (+ другие вендоры) также покрывают тот сегмент. Ему дали имя density optimized (на равне с rack, tower, blade).
Предполагается, что окупаемость данного решения будет только в том случае, если данная система будет заполнена сразу и полностью и иметь постоянную близкую к 100% нагрузку.
А в реальности: сегодня есть заказчик, завтра — уже нет. Такое решение сложно перепрофилировать под другие задачи, без серьезных, подчас дорогостоящих, изменений «начинки».
Даже заказчики с 50-ю серверными стойками в своем ЦОДе не спешит рассматривать подобные решения, это, как минимум, заранее менее гибкая архитектура.
Не спешат, верно. С только продуктовой точки зрения почти всегда появляется подобный негатив, многие блейд-системы начинают ставить в пику, многие — стандартные системы. Обычно в проектах где они появляются начинают с характеристик дата-центра или задач, потом PUE, TFLOPS/Rack/Unit, Вт и прочее. И довольно часто получается выгода именно от (возьму шире, чем объект статье) shared infrastructure системы оказываются более удобными и целесообразными, чем рэк или блейд (банально плотнее+менее потребляющее). Среди shared infrastructure систем много моделей и сегодня рассказ шёл про C8000.
Всё хорошо, но у меня простой вопрос: вы действительно считаете, что провайдеры облаков будут бегать и менять конфигурацию железа в стойках под каждого нового клиента? Это уже не облако получается, ни с какой стороны (On-demand self-service).
Данная система предлагается как конструктор. Бегать и менять конфигурации, действительно, не самое лучшее сравнение :) (хотя такой сценарий нельзя исключать). Скорее имеется в виду возможность гибко подбирать необходимые конфигурации под конкретные роли и задачи узлов.
Тогда не надо использовать слово «облако».

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

Тьфу да и только.
Опять же, облачная модель использования инфраструктуры — один из вариантов. Помимо этого в статье присутствуют и другие. Да и если для микроплатежей понадобится многоузловая система с, к примеру, хорошей фермой для веб-морды и процессинга транзакций, то очень даже PowerEdge C может подойти. Не обязательно модель C8000, но C6220 (a la double twin) вполне.
Вы не поняли — я высказал вам своё презрение о том, что вы готовы прилепить любое модное словечко к тому, что пытаетесь продать, вне зависимости от того, имеет это смысл или нет.

Это приводит к тому, что всё, что вы пишите, начинает выглядеть крайне недостоверно и вы, скорее, портите имидж компании, нежели помогаете ей.

оценить эту конфигурацию — наверное можно. Было бы. Если бы не рекламный булшит, которым вы его обмазали.
не может данная система быть облачной, облако подразумевает и сеть, и SAN и т.п., тут всего этого НЕТ!
Какие же вы неугомонные. Где тут написано, что это облачная система? В статье слово облако встречается 6 раз — 4 раза в описании гипотетического провайдера, который может оказывать «облачные» услуги в понимании «как сервис» + два раза в описании типовых задач. Это компонент для построения в т.ч. и облачных инфраструктур.
А таки если перейти от риторических вопросов облако не облако — как используется модуль с дисками?
Выше в начале добавил ответ.
Весь казус в том, что облако это не выделение простых железных ресурсов.
Если рассматривать самый простой вариант IaaS — инфраструктура как сервис, то данная схема подразумевает под собой не только процы-диски-память, это ещё и сетевая часть, и ОС, гипервизоры, ПО управления и мониторинга, оркестраторы и т.п. инструманты.

Ниодин провайдер не будет ставить кучу разных GPU модулей за свой счёт под 1 клиента, который может «сбежать». провайдер работает на принципе универсальности. Ведь сегодня 1 клиент сбежал, а завтра пришёл новый, которому надо хорошую математическую молотилку, без графики. И что, вытягиваем GPU модули, ложим на полку? Ведь они сейчас не нужны… Но ведь их уже купили, и они должны приностить прибыль, а не лежать «в чулане»…
Так что для публичных облаков, описаных в вашем примере, данная система не особо подходит…
Всё верно, но вы проецируете свойства системы только на задачу организации облачной инфраструктуры. Помимо этой задачи, в статье описаны и HPC, и хостинг, и Big Data-решения и пр. Если у вас только хостинг — берите много маломощных узлов, ставьте Parallels (недавно, вроде сертифицировали линейку PowerEdge C) и предоставляйте. Если HPC для задач готовых к GPGPU — ставьте модули с GPGPU. Вся прелесть в этом и заключается — на этой платформе можно реализовывать множество сценариев.
Использование довольно мощных графических вычеслений это всегда была отдельная ниша, так что не стоит смешивать рендеринг и «обычные облака», как вы писали:)
Так и не мешаем ))) Предлагаем выбор!
Sign up to leave a comment.