Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
А как с обратной совместимостью с оборудованием от старых шасси (c7000)? Сервера я так понял нужны свои, а интерконнекты?
Наличие оптики внутри интересно, но внушает опасение. Что будет с механической прочностью и пылью на этих коннектах? Или там есть какая-то хитрая механика прикрывающая порт в отстутсвии сервера.
Как выглядят оптические коннекторы у меня информации нет, но есть два предположения. На фото внутренности корзины куда вставляется сервер, стрелками обозначены возможные места расположения световодов, зеленой стрелкой обозначен штырь входящий в основной разъем сервера, красными стрелками обозначены шторки за которыми могут скрываться разъемы световодов.
С большим опозданием начинают идеи у циски брать. Которые раньше были «плохими».
А теперь вот и коммутаторы-сателлиты появились… И многое другое ))
А теперь вот и коммутаторы-сателлиты появились… И многое другое ))
В использовании коммутаторов сателлитов нет ничего плохого вне зависимости от вендора, blade решение от Cisco имеет свои нюансы, основная часть которых заключается в отсутствии поддержки транспорта FC без инкапсуляции.
Проще 48-96 портовый Top of rack Arista 71xx/72xx или Huawei CE68xx поставить, и напрямую серверы вокнуть. Дешевле блейд-коммутаторов получится.
Медь в стойке это вчерашний день, хотя конечно дешевле спора нет.
Оптические естественно c SFP+/QSFP+. 48х портовый 10Gb дата центровый ToR с поддержкой FCF/FCoE, VxLAN, SDN ready стоит от $12K c НДС.
48x 10Gb портовый коммутатор потупее без VXLAN, FCOE от $8K.
100м SFP+ трансивер $120-150 в лист прайсе. DAC'и естественно в 2-3 раза дешевле.
48x 10Gb портовый коммутатор потупее без VXLAN, FCOE от $8K.
100м SFP+ трансивер $120-150 в лист прайсе. DAC'и естественно в 2-3 раза дешевле.
При использовании коммутаторов Top of Rack (ToR) внутри стойки все равно будет медь и при большой плотности оборудования её будет много. Если считать blade серверы с коэффициентом плотности 1.6 сервера на юнит (HPE, DELL) и если требуется по два линка на сервер, то в 42U стойке нужно будет проложить 128 патчкордов. Надежность такого решения будет небольшая, все же электроника это наука о плохих контактах, не говоря о том, что нужно еще поискать человека который сможет правильно уложить всю эту медь в стойке и сохранять порядок при переключениях линков на протяжении всего срока эксплуатации ДЦ. В случае использования классических blade коммутаторов потребуется всего 16 оптических патчкордов, а при подключении четырех корзин Synergy будет достаточно всего двух QSFP кабелей.
В скольки датацентрах Вы видели питание более 15 кВт на стойку?
15кВт это 2х блейд-шасси на стойку (20-24U) или если очень оптимистично 3х блейд-шасси (36U).
Обычно в датацентрах с воздушным охлаждением 6-12 кВт. С такой нагрузкой ещё можно использовать free cooling. Т.е. это в прыжке 2х блейд-шасси и пол шкафа не проданного воздуха. Т.е. преимущество в плотности — это маркетинг.
Жизнь показала, проще поставить стандартные 2U серверы с дисками, с KVM, oVirt/OpenStack, Ceph (SDS) и не любить голову.
На 6кВт стойку это до 12х серверов, 4х 10Gb порта на сервер, и 48x портовый 10Gb ToR. 48 линков на стойку, не так и много.
При нагрузке 6-12кВт на стойку, отказ половины кондеев в контейнере/гермозоне не приводит к meltdown)
15кВт это 2х блейд-шасси на стойку (20-24U) или если очень оптимистично 3х блейд-шасси (36U).
Обычно в датацентрах с воздушным охлаждением 6-12 кВт. С такой нагрузкой ещё можно использовать free cooling. Т.е. это в прыжке 2х блейд-шасси и пол шкафа не проданного воздуха. Т.е. преимущество в плотности — это маркетинг.
Жизнь показала, проще поставить стандартные 2U серверы с дисками, с KVM, oVirt/OpenStack, Ceph (SDS) и не любить голову.
На 6кВт стойку это до 12х серверов, 4х 10Gb порта на сервер, и 48x портовый 10Gb ToR. 48 линков на стойку, не так и много.
При нагрузке 6-12кВт на стойку, отказ половины кондеев в контейнере/гермозоне не приводит к meltdown)
В скольки датацентрах Вы видели питание более 15 кВт на стойку?Лично был в 7 или 8 ДЦ с питанием более 15 кВт на стойку. Если считать стоимость юнита в ДЦ Tier 3, то она получается близка к стоимости 1U сервера средних характеристик А бренда, поэтому плотность вычислительных ресурсов на юнит может играть большую роль. Если брать наиболее плотные решения (HP и DELL) с 32 CPU (тепловой пакет каждого CPU 135W) на 10U, реальная потребляемая мощность будет около 4кВт при использовании серверов для VM. Итого на стойку получится 16кВт, в реальности эта цифра будет близка к 12кВт на 4 корзины, если конечно биткоины не считать))
Осталось озвучить как оно по цене в соотношении с с7000 :)
ого =) я только в теории изучал и серию написал, а тут уже и практика есть.
вам в россии удалось протестировать, или зарубежом? в заказчике, партнере, вендоре?
вам в россии удалось протестировать, или зарубежом? в заказчике, партнере, вендоре?
«Composer представляет из себя мини сервер х86 архитектуры с модифицированным ядром Linux.»
Хм-м-м, а почему не ARM? Что там за задачи такие, что ARM не справляется?
«Данный сервер содержит процессоры Xeon E5 четвертого поколения»
Мне не нравится то, что нет свободы выбора процессоров. Очень хотелось бы иметь возможность использовать процессоры ARM, другие RISC-процессоры, более слабые (и соответственно, слабые дешёвые) процессоры Intel и процессоры AMD — на выбор.
Например, ряд атак (прежде всего — с забросом на сервер своего программного кода с попыткой заставить сервер выполнить этот код) предполагают, что на сервере работает конкретный тип процессора. А если там процессор с другим набором команд — то атака заведомо зафейлится.
Хм-м-м, а почему не ARM? Что там за задачи такие, что ARM не справляется?
«Данный сервер содержит процессоры Xeon E5 четвертого поколения»
Мне не нравится то, что нет свободы выбора процессоров. Очень хотелось бы иметь возможность использовать процессоры ARM, другие RISC-процессоры, более слабые (и соответственно, слабые дешёвые) процессоры Intel и процессоры AMD — на выбор.
Например, ряд атак (прежде всего — с забросом на сервер своего программного кода с попыткой заставить сервер выполнить этот код) предполагают, что на сервере работает конкретный тип процессора. А если там процессор с другим набором команд — то атака заведомо зафейлится.
Хм-м-м, а почему не ARM? Что там за задачи такие, что ARM не справляется?Если управлять одним шасси, то думаю что хватит и ARM, но если 20 шт. то видимо уже нет.
Мне не нравится то, что нет свободы выбора процессоров. Очень хотелось бы иметь возможность использовать процессоры ARM, другие RISC-процессоры, более слабые (и соответственно, слабые дешёвые) процессоры Intel и процессоры AMD — на выбор.Никто не мешает использовать RISC-процессоры, для этого есть HPE Moonshot (Кстати тоже занимался его тестированием), там совсем другая плотность, архитектура и круг решаемых задач.
Например, ряд атак (прежде всего — с забросом на сервер своего программного кода с попыткой заставить сервер выполнить этот код) предполагают, что на сервере работает конкретный тип процессора. А если там процессор с другим набором команд — то атака заведомо зафейлится.Вредоносный код использующий уязвимости ядра ОС, пишется под определенные версии ядра, а версия ядра напрямую зависит от архитектуры CPU. Чем меньше распространена версия ядра, тем меньше у нее обнаруженных уязвимостей.
А сколько процессорной мощности требует управление одним шасси?
Вредоносный код может никак не использовать ядро, а обращаться к библиотекам, как это делают все нормальные программы. Кроме того, одна конкретная версия программы может работать на широком диапазоне ядер — например, на W'95/98 и на W'NT/2000/XP (ядра там сильно разные). Во FreeBSD бинарная совместимость обычно сохраняется вплоть до смены старшей цифры в номере версии — т.е. от 5.0 до 5.4 совместимость полная.
Если брать за пример FreeBSD, то он работает на разных архитектурах (см.ихний сайт). При этом версия ядра и всей операционки — одна и та же.
Вредоносный код может никак не использовать ядро, а обращаться к библиотекам, как это делают все нормальные программы. Кроме того, одна конкретная версия программы может работать на широком диапазоне ядер — например, на W'95/98 и на W'NT/2000/XP (ядра там сильно разные). Во FreeBSD бинарная совместимость обычно сохраняется вплоть до смены старшей цифры в номере версии — т.е. от 5.0 до 5.4 совместимость полная.
Если брать за пример FreeBSD, то он работает на разных архитектурах (см.ихний сайт). При этом версия ядра и всей операционки — одна и та же.
Какой теперь у HP лозунг? Конвергентная адаптивность или адаптация конвергентности?
Мир разворачивается в сторону микросервисов. Зачем теперь вот это всё?
Под oVirt, Openstack, Docker, Ceph дешевле поставить DL160, и выкинуть (вернуть лизингодателю) через 3 года.
Или ещё проще использовать что то типа HPE Apollo 2000.
Мир разворачивается в сторону микросервисов. Зачем теперь вот это всё?
Под oVirt, Openstack, Docker, Ceph дешевле поставить DL160, и выкинуть (вернуть лизингодателю) через 3 года.
Или ещё проще использовать что то типа HPE Apollo 2000.
Для каждой задачи нужно использовать подходящее оборудование, Synergy это Enterprise решение. Контейнеры можно разворачивать и на десктопах, используя при этом SDS, но какой будет уровень надежости и масштабируемости системы? Да и не каждую задачу можно решить контейнерным способом, тяжелую БД в контейнер или на слабое железо не запихнешь.
Основная идея, которая продвигается данным решением — это инфраструктура как софт, так называемая «Composable Infrastructure», т.е. фактические нет привязки к аппаратному обеспечению — есть вычислительные блоки и блоки хранения + софт управления всем этим.
Выделение и ввредение в работу ресурсов (без разницы аппаратных или виртуальных) происходит фактически без вмешательства администрируещего персонала — достаточно применить профиль на бей/сервер и система сама присвоит MAC/WWN, зальет и развернет образ ОС.
Также, не стоит забывать о разных подходах в Enterprise и Cloud сегментах. Контейнеризация, как и виртуализация решает многое, но далеко не все.
Выделение и ввредение в работу ресурсов (без разницы аппаратных или виртуальных) происходит фактически без вмешательства администрируещего персонала — достаточно применить профиль на бей/сервер и система сама присвоит MAC/WWN, зальет и развернет образ ОС.
Также, не стоит забывать о разных подходах в Enterprise и Cloud сегментах. Контейнеризация, как и виртуализация решает многое, но далеко не все.
Это сказка для того чтобы продать vendor lock-in.
HP Oneview конечно прекрасен, но работает только с оборудованием HP. Его ждет та же судьба, что и HP Matrix.
Зачем виртуальные MAC/WWN? Сейчас нет уникальных серверов, все на виртуалках.
Вся HA/DR логика находится на гипервизорах, логика управления сетью на Open vSwitch, OVS, vSwitch, NSX. LUN СХД презентуется сразу порт группе.
OS deployment умеют все, любой сервер поддерживает ipmi, PXE. Windows WDS, Linux умеет деплоиться на bare metal.
Puppet, Ansible прекрасно умеет работать с коммутаторами Arista, Juniper и нарезать VLAN'ы, QoS во время деплоя серверов.
Проще использовать OpenSource набор утилит для monitoring, deploy, provisioning чем вендорские костыли.
Пора учиться продавать DevOps, как Arista, а не Ынтерпайз и Прэмиум )
HP Oneview конечно прекрасен, но работает только с оборудованием HP. Его ждет та же судьба, что и HP Matrix.
Зачем виртуальные MAC/WWN? Сейчас нет уникальных серверов, все на виртуалках.
Вся HA/DR логика находится на гипервизорах, логика управления сетью на Open vSwitch, OVS, vSwitch, NSX. LUN СХД презентуется сразу порт группе.
OS deployment умеют все, любой сервер поддерживает ipmi, PXE. Windows WDS, Linux умеет деплоиться на bare metal.
Puppet, Ansible прекрасно умеет работать с коммутаторами Arista, Juniper и нарезать VLAN'ы, QoS во время деплоя серверов.
Проще использовать OpenSource набор утилит для monitoring, deploy, provisioning чем вендорские костыли.
Пора учиться продавать DevOps, как Arista, а не Ынтерпайз и Прэмиум )
HPE OneView поддерживает не тольколь HPE, как минимум еще Cisco и Brocade, но сервера и СХД только HPE.
По моим данным потребности в физической инфрастуктуре все еще высоки, т.к. некоторые производители корпроративного ПО до сих пор не сертифицировали ни один из известных гипервизоров.
Виртуализация ввода/вывода на уровне WWN и MAC опять таки необходимы при замене физических серверов.
И да, данное решение не позиционируется как альтернатива Cloud решений от opensource сообщества — это параллельно существующее направление.
Если рынок хочет получить решение уровня Synergy, 3PAR и т.д. значит оно ему надо. :)
По моим данным потребности в физической инфрастуктуре все еще высоки, т.к. некоторые производители корпроративного ПО до сих пор не сертифицировали ни один из известных гипервизоров.
Виртуализация ввода/вывода на уровне WWN и MAC опять таки необходимы при замене физических серверов.
И да, данное решение не позиционируется как альтернатива Cloud решений от opensource сообщества — это параллельно существующее направление.
Если рынок хочет получить решение уровня Synergy, 3PAR и т.д. значит оно ему надо. :)
HP OneView конечно прекрасен, но работает только с оборудованием HP. Его ждет та же судьба, что и HP Matrix.OneView это софт управления а HP Matrix это проприетарное облачное решение на itanium.
Зачем виртуальные MAC/WWN?Железо для виртуальных серверов тоже нудно менять, и если их десяток, то это не проблема, но когда инфраструктура большая, Synergy может заметно упростить работу администраторам.
LUN СХД презентуется сразу порт группе.Это вообще как? Зонинг по портам, и all acсess на массиве, и кто подключился к порту тот и получил доступ к LUN? Такой подход возможен только с малым кол-вом SAN портов и имеет значительные ограничения.
Проще использовать OpenSource набор утилит для monitoring, deploy, provisioning чем вендорские костыли.Основная разница между Enterprise и OpenSource решениями в том кто будет виноват когда что-либо сломается, чинить OpenSource придется самому и никто тут не поможет. Вопрос в критичности бизнеса, в одном случае оптимальным будет применение OpenSource в другом Enterprise, как говориться не надо грести лопатой и копать веслом )
Возникает вопрос: какой смысл в 10 юнитовой корзине на 10 серверов? )))) Когда в те же 10 юнитов можно засунуть 10 классических серверов сопоставимой производительности?
Какой смысл в блэйдах, если они не обеспечивают высокую плотность размещения оборудования?
Ну и очень печальна завязка на функционально убогий и логически кривой virtual connect. Который часто вызывает большие проблемы. Т.к. в нем толком не разбираются и не хотят связываться ни администраторы этих самых блейдов, ни сетевые администраторы.
Какой смысл в блэйдах, если они не обеспечивают высокую плотность размещения оборудования?
Ну и очень печальна завязка на функционально убогий и логически кривой virtual connect. Который часто вызывает большие проблемы. Т.к. в нем толком не разбираются и не хотят связываться ни администраторы этих самых блейдов, ни сетевые администраторы.
какой смысл в 10 юнитовой корзине на 10 серверов?Ну все же корзина не на 10 серверов а на 12, но конечно коэффициент плотности на текущих CPU разочаровывает.
Какой смысл в блэйдах, если они не обеспечивают высокую плотность размещения оборудования?Смысл есть в консолидации управления, когда серверов много (несколько тысяч) методы прекрасно работающие на нескольких сотнях перестают работать.
Ну и очень печальна завязка на функционально убогий и логически кривой virtual connect.Тут согласен, к классическому Virtual Connect большинство относиться с предубеждением и я в их числе, но знаю людей которые от них в восторге и используют те фишки, которых нет в других blade коммутаторах. С другой стороны интерфейс управления для Virtual Connect в Synergy переработан полностью, и показался мне более интуитивно понятным по сравнению с предыдущим.
А какие такие плюсы в управлении дают эти блейды по сравнению с обычными серверами?)
И почему яндексы, гуглы и т.д. используют обычные сервера вместо блейдов?
ИМХО если например говорить про ту же циску — там хотя бы реально продают готовую инфраструктуру на 30 корзин с одной точкой управления и готовым интерконектом.
А тут собери, спроектируй, настрой по отдельности…
Жалкое число возиможных коммутаторо-саттелитов. Почему бы их не сделать больше, а головной интергонект вывести из корзины? )))
Больше напоминает коробку с обычныи компонентами.
Понятно, что ХП конечно более гибкий для специфических задач, умеет родной FC, наверняка IB интерконекты будут и т.д…
И почему яндексы, гуглы и т.д. используют обычные сервера вместо блейдов?
ИМХО если например говорить про ту же циску — там хотя бы реально продают готовую инфраструктуру на 30 корзин с одной точкой управления и готовым интерконектом.
А тут собери, спроектируй, настрой по отдельности…
Жалкое число возиможных коммутаторо-саттелитов. Почему бы их не сделать больше, а головной интергонект вывести из корзины? )))
Больше напоминает коробку с обычныи компонентами.
Понятно, что ХП конечно более гибкий для специфических задач, умеет родной FC, наверняка IB интерконекты будут и т.д…
Cisco вообще то собирается в своих системах HyperFlex уйти от корзин и использовать юнитовые сервера в hyperconverged решениях
И почему яндексы, гуглы и т.д. используют обычные сервера вместо блейдов?Google и Яндекс используют архитектуру отказоустойчивости на уровне приложения, если сломается железо или целый ДЦ, пользователи этого могут и не заметить, просто нет смысла использовать дорогое железо.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
HPE Synergy, опыт реальной эксплуатации