Хм… ну все ткак то больше плюшками балуемся. Я на доступ к СХД вам показываю (просто как на очевидную брешь в Вашем подходе), а тут Циско с Нексусом и FCOE и тем более iSCSI ну никак не катит. Ну и у vmware (одиноко стоящего) тоже все не очень с этим хорошо. Руки, ноги, крылья… главное хвост! Перетащить сеть есть маленькое четвертьдела. Да и для мишнкритикл все таки Юникс онли пока. При довольно дорогом часе простоя очень странно, что у Вас не Юникс.
Насчет сетевое у НР не дотягивает — сильно поспорю (с приобретением 3COM линейка стала практически полной). А вот аналога виртуального коннекта у Циски нет, а ей очень хочется (увидите). Недаром же Циско пошла на рынок блэйдов (пока со слабым успехом однако — до НР, простите, пока очень далеко)
На последний вопрос ответ прост — у меня главные сервисы — мобильник и ноутбук и их внеплановые остановки очень болезненны :), причем не для меня.
«Бездоказательно Ватсон». «Ограничение механизмов работы технологий». Так и хочется сказать, что если технологии что то не умеют их надо менять. Интересно, а почему мы потеряем всего 40 %, а не 99%?
Кроме того так и хочется спросить: месяц назад мы увеличили полосу пропускания в 10 раз (с 1 Гбита на 10) и нам уже не хватает 0.6 от новой полосы?
Тем не менее, давайте поговорим именно о ВИРТУАЛЬНОСТИ Virtual Connect. Наверное, это самое главное!
Итак сценарий номер 1: у Вас используются эти так называемые нормальные коммутаторы. Замечательно! Но вот незадача, у Вас сгорел сервер — синим пламенем, заметьте сгорел (мы не будем обсуждать почему). В случае традиционных коммутаторов нам нужно для ремонта собрать как минимум троих профессионалов (сетевика, сисадмина и админа СХД) ибо замене сервера повлечет некоторые перестройки в СХД, сети и массивах. Пускай у нас очень шустрые админы и делают все в доли секунды (заметим, что бизнес-пользователи громко кричат и топают ногами, потеряв возможность нажимать кнопки). Наверное все уже понятно. Или я неправ и у Вас все на кластерах и оборудовании с уровнем доступности пять девяток и жестко прописанные и соблюдаемые SLA? Нет?
Сценарий номер 2: у Вас VC. Тогда у Вас два выбора
— мувнуть профиль сервера на запасной (spare) причем сие можно автоматизировать
— тупо поменять блейд (при этом MAC и WWN) не изменятся — с точки зрения внешнего мира это тот же сервер
В результате сервер весело грузится с внешнего массива. Ура! ИТ-сервис восстановлен!
Еще вопросик, а кто сказал, что технология VC не позволяет работать с FCOE? Даже странно как то — это логичное развитие.
Ну и наконец, а я и не отрицаю нормальный конвергентный коммутатор (конечно же Brocade или Procurve). Все определяется бизнес-задачей в соответствии с ITIL. Как это написано «миссия ИТ — underpinning бизнеса». Вот и пускай она андерпиннит бизнес, а не наоборот.
Заметим, что я пока молчу, что если в 10 Гбитах выделить 8 Гбит на доступ СХД, как сейчас дает один порт FC…
Продолжение следует… :) И вот ведь незадача, аналогов VC у конкурентов пока нет, хотя они над этим (по слухам) упорно работают :)
Хм… Уважаемый Amaro, а вот с какой целью Вы интересуетесь? Самообразование или есть конкретная задача по организации конкретного ИТ-сервиса для бизнеса? Стремление решить и ту и другую задачу похвально, но не забываем, что для решения первой задачи существуют учебные центры, а для решения второй системные интеграторы.
Я бы не хотел здесь организовывать обсуждение не много страниц :)
Скажу коротко: FC давно и очень успешно применяется там, где нужна самая высокая производительность и это воистину древний стандарт и очень хорошо «заточенный» как раз для создания СХД. Минимальная латентность, пакеты не теряются бесследно и много другого полезного.
Как говорил Карл Маркс (кажется) «практика — критерий истины». В нашем случае критерий — выбор рынка. А он как раз пока в пользу FC. Вы же не будете отрицать, что технологии служат целям ведения бизнеса (как учит нас ITIL) :)
Ethernet всегда был предназначен совсем для другого. И как Вы планируете организовать доступ к массивам через 10 Гбит Ethernet? Через iSCSI? Неплохо… неплохо… но не для хай-энда. Через FCOE? Уже лучше, но вот незадача, выбор оборудования пока не столь широк — стандарт молодой.
Скажем так — каждому овощу свое время. FCOE быть однозначно и это будет уже совсем другая история — конвергенция.
Если бы Flex-10 был коммутатором, это было бы верно. Flex-10 позволяет резать 10 Гбит LOM (интегрированный LAN адаптер) на несколько виртуальных и устанавливать для них скорость. Поэтому 40 % нам не грозит :)
1) Это не лучше и не хуже — это оборудование для построения SAN сетей
2) Это разное оборудование, поэтому сравнение бессмысленно
2а) Устройства — дисковые массивы FC (MSA, EVA и много еще)
2б) Именно — FC HBA в сервера
NOTE: Flex-10 capability requires the use of an HP Virtual Connect Flex-10 10Gb Ethernet module. Learn more at: www.hp.com/go/virtualconnect
NOTE: Fibre Channel over Ethernet (FCoE) capability requires the use of an HP Virtual Connect FlexFabric 10Gb/24-port Module. Learn more at: www.hp.com/go/virtualconnect
Если купить Qlogic, Emulex или Brocade, можно подключить их к SAN Dirextor от Brocade и мы получим классический могучий FC для доступа к внешней СХД.
Конвергентный адаптер, это действительно только часть решения. И у НР есть ПОЛНОЕ РЕШЕНИЕ на эту тему. Именно сертифицированные решения лежат в основе «нормальной IT инфраструктуры.»
Cisco тоже пытается сделать полное решение и Нексус только часть его
Не надо пожалуйста называть Flex-10 непонятным трубопроводом. Если так, то мой вопрос: для кого непонятным? :)
Единственно, где это хоть как то может быть оправдано — при удаленной репликации и паршивом канале :)
Насчет сетевое у НР не дотягивает — сильно поспорю (с приобретением 3COM линейка стала практически полной). А вот аналога виртуального коннекта у Циски нет, а ей очень хочется (увидите). Недаром же Циско пошла на рынок блэйдов (пока со слабым успехом однако — до НР, простите, пока очень далеко)
На последний вопрос ответ прост — у меня главные сервисы — мобильник и ноутбук и их внеплановые остановки очень болезненны :), причем не для меня.
Продолжение следует…
Кроме того так и хочется спросить: месяц назад мы увеличили полосу пропускания в 10 раз (с 1 Гбита на 10) и нам уже не хватает 0.6 от новой полосы?
Тем не менее, давайте поговорим именно о ВИРТУАЛЬНОСТИ Virtual Connect. Наверное, это самое главное!
Итак сценарий номер 1: у Вас используются эти так называемые нормальные коммутаторы. Замечательно! Но вот незадача, у Вас сгорел сервер — синим пламенем, заметьте сгорел (мы не будем обсуждать почему). В случае традиционных коммутаторов нам нужно для ремонта собрать как минимум троих профессионалов (сетевика, сисадмина и админа СХД) ибо замене сервера повлечет некоторые перестройки в СХД, сети и массивах. Пускай у нас очень шустрые админы и делают все в доли секунды (заметим, что бизнес-пользователи громко кричат и топают ногами, потеряв возможность нажимать кнопки). Наверное все уже понятно. Или я неправ и у Вас все на кластерах и оборудовании с уровнем доступности пять девяток и жестко прописанные и соблюдаемые SLA? Нет?
Сценарий номер 2: у Вас VC. Тогда у Вас два выбора
— мувнуть профиль сервера на запасной (spare) причем сие можно автоматизировать
— тупо поменять блейд (при этом MAC и WWN) не изменятся — с точки зрения внешнего мира это тот же сервер
В результате сервер весело грузится с внешнего массива. Ура! ИТ-сервис восстановлен!
Еще вопросик, а кто сказал, что технология VC не позволяет работать с FCOE? Даже странно как то — это логичное развитие.
Ну и наконец, а я и не отрицаю нормальный конвергентный коммутатор (конечно же Brocade или Procurve). Все определяется бизнес-задачей в соответствии с ITIL. Как это написано «миссия ИТ — underpinning бизнеса». Вот и пускай она андерпиннит бизнес, а не наоборот.
Заметим, что я пока молчу, что если в 10 Гбитах выделить 8 Гбит на доступ СХД, как сейчас дает один порт FC…
Продолжение следует… :) И вот ведь незадача, аналогов VC у конкурентов пока нет, хотя они над этим (по слухам) упорно работают :)
Я бы не хотел здесь организовывать обсуждение не много страниц :)
Скажу коротко: FC давно и очень успешно применяется там, где нужна самая высокая производительность и это воистину древний стандарт и очень хорошо «заточенный» как раз для создания СХД. Минимальная латентность, пакеты не теряются бесследно и много другого полезного.
Как говорил Карл Маркс (кажется) «практика — критерий истины». В нашем случае критерий — выбор рынка. А он как раз пока в пользу FC. Вы же не будете отрицать, что технологии служат целям ведения бизнеса (как учит нас ITIL) :)
Ethernet всегда был предназначен совсем для другого. И как Вы планируете организовать доступ к массивам через 10 Гбит Ethernet? Через iSCSI? Неплохо… неплохо… но не для хай-энда. Через FCOE? Уже лучше, но вот незадача, выбор оборудования пока не столь широк — стандарт молодой.
Скажем так — каждому овощу свое время. FCOE быть однозначно и это будет уже совсем другая история — конвергенция.
2) Это разное оборудование, поэтому сравнение бессмысленно
2а) Устройства — дисковые массивы FC (MSA, EVA и много еще)
2б) Именно — FC HBA в сервера
NOTE: Flex-10 capability requires the use of an HP Virtual Connect Flex-10 10Gb Ethernet module. Learn more at: www.hp.com/go/virtualconnect
NOTE: Fibre Channel over Ethernet (FCoE) capability requires the use of an HP Virtual Connect FlexFabric 10Gb/24-port Module. Learn more at: www.hp.com/go/virtualconnect
Конвергентный адаптер, это действительно только часть решения. И у НР есть ПОЛНОЕ РЕШЕНИЕ на эту тему. Именно сертифицированные решения лежат в основе «нормальной IT инфраструктуры.»
Cisco тоже пытается сделать полное решение и Нексус только часть его
Не надо пожалуйста называть Flex-10 непонятным трубопроводом. Если так, то мой вопрос: для кого непонятным? :)
iSCSI — да. Но он и не претендует на высокую производительность… пока