Наверное, имелось ввиду: «чаще имеем дело с живыми СХД», ну по крайней мере я на это надеюсь) Проблемы производительности на back-end СХД самые простые по диагностике, ну если конечно конфигурация самого СХД корректна и есть механизм мониторинга. А восстановление данных это дело не простое и не дешевое, при этом у каждого вендора есть спец софт, которым они обычно не делятся, а потом как договоришься, если оборудование на поддержке и данные попортились не по вине админов, то могут и бесплатно сделать.
Если что, это был сарказм) Спорить с оппонентом, который без аргументов переходит на критику дело неблагодарное. А если по существу, то есть время обработки запроса носителем информации в составе СХД, и есть время обработки запроса всего СХД. И тут говоря про задержки на носителе, нужно упоминать носитель, и никакой путаницы не будет. Во многих СХД используются алгоритмы оптимизации, носитель уже передал данные в кеш контроллера, и только потом пришел запрос на чтение этих данных.
Зависимость задержек чтения/записи от процента утилизации контроллера очень нелинейна, например задержки при 1% и при 50% могут быть одинаковые, а при 70% и 80% различаться в два раза.
Зависимость задержек чтения/записи от процента утилизации контроллера очень нелинейна, например задержки при 1% и при 50% могут быть одинаковые, а при 70% и 80% различаться в два раза.
И почему яндексы, гуглы и т.д. используют обычные сервера вместо блейдов?
Google и Яндекс используют архитектуру отказоустойчивости на уровне приложения, если сломается железо или целый ДЦ, пользователи этого могут и не заметить, просто нет смысла использовать дорогое железо.
Не знаю почему, но не люблю Huawei, наверное потому что продавцы у них очень сильно хотят тебе что-то продать, у меня этот метод работы ассоциируется с продажами пылесосов по квартирам))) При этом среди железа у них есть достойные модели, RH8100 в том числе.
В скольки датацентрах Вы видели питание более 15 кВт на стойку?
Лично был в 7 или 8 ДЦ с питанием более 15 кВт на стойку. Если считать стоимость юнита в ДЦ Tier 3, то она получается близка к стоимости 1U сервера средних характеристик А бренда, поэтому плотность вычислительных ресурсов на юнит может играть большую роль. Если брать наиболее плотные решения (HP и DELL) с 32 CPU (тепловой пакет каждого CPU 135W) на 10U, реальная потребляемая мощность будет около 4кВт при использовании серверов для VM. Итого на стойку получится 16кВт, в реальности эта цифра будет близка к 12кВт на 4 корзины, если конечно биткоины не считать))
Ну все же корзина не на 10 серверов а на 12, но конечно коэффициент плотности на текущих CPU разочаровывает.
Какой смысл в блэйдах, если они не обеспечивают высокую плотность размещения оборудования?
Смысл есть в консолидации управления, когда серверов много (несколько тысяч) методы прекрасно работающие на нескольких сотнях перестают работать.
Ну и очень печальна завязка на функционально убогий и логически кривой virtual connect.
Тут согласен, к классическому Virtual Connect большинство относиться с предубеждением и я в их числе, но знаю людей которые от них в восторге и используют те фишки, которых нет в других blade коммутаторах. С другой стороны интерфейс управления для Virtual Connect в Synergy переработан полностью, и показался мне более интуитивно понятным по сравнению с предыдущим.
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, как говориться не надо грести лопатой и копать веслом )
При использовании коммутаторов Top of Rack (ToR) внутри стойки все равно будет медь и при большой плотности оборудования её будет много. Если считать blade серверы с коэффициентом плотности 1.6 сервера на юнит (HPE, DELL) и если требуется по два линка на сервер, то в 42U стойке нужно будет проложить 128 патчкордов. Надежность такого решения будет небольшая, все же электроника это наука о плохих контактах, не говоря о том, что нужно еще поискать человека который сможет правильно уложить всю эту медь в стойке и сохранять порядок при переключениях линков на протяжении всего срока эксплуатации ДЦ. В случае использования классических blade коммутаторов потребуется всего 16 оптических патчкордов, а при подключении четырех корзин Synergy будет достаточно всего двух QSFP кабелей.
Как выглядят оптические коннекторы у меня информации нет, но есть два предположения. На фото внутренности корзины куда вставляется сервер, стрелками обозначены возможные места расположения световодов, зеленой стрелкой обозначен штырь входящий в основной разъем сервера, красными стрелками обозначены шторки за которыми могут скрываться разъемы световодов.
Для каждой задачи нужно использовать подходящее оборудование, Synergy это Enterprise решение. Контейнеры можно разворачивать и на десктопах, используя при этом SDS, но какой будет уровень надежости и масштабируемости системы? Да и не каждую задачу можно решить контейнерным способом, тяжелую БД в контейнер или на слабое железо не запихнешь.
Хм-м-м, а почему не ARM? Что там за задачи такие, что ARM не справляется?
Если управлять одним шасси, то думаю что хватит и ARM, но если 20 шт. то видимо уже нет.
Мне не нравится то, что нет свободы выбора процессоров. Очень хотелось бы иметь возможность использовать процессоры ARM, другие RISC-процессоры, более слабые (и соответственно, слабые дешёвые) процессоры Intel и процессоры AMD — на выбор.
Никто не мешает использовать RISC-процессоры, для этого есть HPE Moonshot (Кстати тоже занимался его тестированием), там совсем другая плотность, архитектура и круг решаемых задач.
Например, ряд атак (прежде всего — с забросом на сервер своего программного кода с попыткой заставить сервер выполнить этот код) предполагают, что на сервере работает конкретный тип процессора. А если там процессор с другим набором команд — то атака заведомо зафейлится.
Вредоносный код использующий уязвимости ядра ОС, пишется под определенные версии ядра, а версия ядра напрямую зависит от архитектуры CPU. Чем меньше распространена версия ядра, тем меньше у нее обнаруженных уязвимостей.
Тестирование проходило в России, была информация что на момент начала тесов это был единственный экземпляр на всю Европу) Пользуясь случаем хочу поблагодарить вас за интересные статьи на данную тему, ссылки были очень кстати.
В использовании коммутаторов сателлитов нет ничего плохого вне зависимости от вендора, blade решение от Cisco имеет свои нюансы, основная часть которых заключается в отсутствии поддержки транспорта FC без инкапсуляции.
Если что, это был сарказм) Спорить с оппонентом, который без аргументов переходит на критику дело неблагодарное. А если по существу, то есть время обработки запроса носителем информации в составе СХД, и есть время обработки запроса всего СХД. И тут говоря про задержки на носителе, нужно упоминать носитель, и никакой путаницы не будет. Во многих СХД используются алгоритмы оптимизации, носитель уже передал данные в кеш контроллера, и только потом пришел запрос на чтение этих данных.
Сильная аргументация, можете остаться при своем мнении.
Медь в стойке это вчерашний день, хотя конечно дешевле спора нет.
Никто не мешает использовать RISC-процессоры, для этого есть HPE Moonshot (Кстати тоже занимался его тестированием), там совсем другая плотность, архитектура и круг решаемых задач.
Вредоносный код использующий уязвимости ядра ОС, пишется под определенные версии ядра, а версия ядра напрямую зависит от архитектуры CPU. Чем меньше распространена версия ядра, тем меньше у нее обнаруженных уязвимостей.