Комментарии 35
Почему RAID-5, а не, н-р, 6?
Не храним там настолько критичные данные, чтобы терять в памяти и скорости при использовании RAID6.
Баланс между скоростью, памятью и надёжностью.
Баланс между скоростью, памятью и надёжностью.
Тогда уж не 5 и не 6, а 50, ака «полтосик» :)
Потеря в объёме будет ровно в один диск, если массив например из 12 дисков по 500 Gb, то RAID5 будет объёмом в 5500 Gb, а RAID6 а 5000Gb. Согласитесь, разница не принципиальная, зато надёжность на порядок выше. По поводу производительности, на большом массиве при преобладающих операциях чтения разница между 5 и 6 будет не столь существенной, в крайнем случае можно было бы установить дополнительный enclasure с дисками.
Это всё бесспорно. Но в любом случае без резервного копирования никуда. Скорее волнует, что диски из одной партии, и посыпаться могут вообще одновременно, там и 6 не спасёт. Это вечный спор, и решение принимается просто как баланс между противоречащими показателями. Мы решили, что 1 ТБ не лишний, и выигрышь в скорости, хоть может и не сильно заметный. Но, конечно, если когда-то умрёт 2 одновременно (тьфу-тьфу-тьфу), то мы пожалеем о принятом решении.
последняя на данный момент версия — XenServer 6.1
Последняя версия XenServer — 6.2.
В семейство XenServer входит несколько версий продукта, отличающиеся ценой и дополнительными функциями.
Начиная с 6.2 есть только одна версия, которая вобрала в себя все редакции.
Web Self Service — начиная с 6.2 больше нет.
Дальше возникает вопрос: где хранить виртуальные машины? Если их хранить на самих серверах, то это уменьшает надёжность системы, т.к. при выходе из строя сервера мы потеряем все виртуальные машины, которые были на нём
Что вы будете делать если сдохнет полка с дисками?
RAID-5 тоже странный выбор. Лучше уж RAID-6, если вам места жалко. Hot Spare-то есть?
Как человек, три с половиной года, потративший на XenServer, могу сказать, что без очень серьёзной доработки напильником на низком уровне (то есть патчи на софт и скрипты) оно неработоспособно.
Например, флуд-атака с rand-source на любую виртуалку парализует работу openvswitch и приводит к отказу management-сети. Антиспуфинг-скрипт глючный и не работает как надо на интерфейсах старше нулевого, миграция приводит к инкрементальным (нарастающим) утечкам памяти. Про «тонкости» работы с VHD даже говорить не приходится — там ад и ужас.
Например, флуд-атака с rand-source на любую виртуалку парализует работу openvswitch и приводит к отказу management-сети. Антиспуфинг-скрипт глючный и не работает как надо на интерфейсах старше нулевого, миграция приводит к инкрементальным (нарастающим) утечкам памяти. Про «тонкости» работы с VHD даже говорить не приходится — там ад и ужас.
>Первой задачей становится выбор основы для любого облака, а именно — выбор серверов
А я думал, что первым делом пишут ТЗ. Для чего это облако? Как вы можете быть уверены, что выбрали верное решение если даже не поставили никакой задачи?
А я думал, что первым делом пишут ТЗ. Для чего это облако? Как вы можете быть уверены, что выбрали верное решение если даже не поставили никакой задачи?
Во-первых не Fiber, а Fibre Channel.
Во-вторых. WSS это не совсем замена XenCenter. Даже из его названия понятно на что он в первую очередь ориентирован, а именно — самообслуживание без участия админа облака. Т.е. самостоятельный реинсталл системы, перезагрузки и прочие базовые операции админами виртуалок. Т.е. с админа снимаются постоянные просьбы типа «виртуалка повисла на перезагрузке, просьба сделать force reboot». Но есть у него одна подлянка. Гипервизоры обычно сидят в сети управления без доступа во внешний мир, а эта зараза может работать только с гипервизорами напрямую — везде в интерфейсе жестко зашиты их адреса, т.е. даже проброс портов не поможет. Но есть сторонний бесплатный вариант без этих ограничений — xvp. Честно говоря мы его не пробовали, т.к. необходимость пропала.
Ну и дальше по мелочи.
Косяк с бубунтой лечится без консоли, просто используем network install и указываем урл.
Плюс не совсем понял на фига использовали таких зверей, как 3850. Вместо четырех серваков лучше бы BaldeCenter взяли и набили их лезвиями в конфигурации типа Foundation for Cloud. И с дисками SSD, а то все брендовое железо и так любит долго стартовать, а тут хоть чуть-чуть время загрузки гипервизора сократите :)
Во-вторых. WSS это не совсем замена XenCenter. Даже из его названия понятно на что он в первую очередь ориентирован, а именно — самообслуживание без участия админа облака. Т.е. самостоятельный реинсталл системы, перезагрузки и прочие базовые операции админами виртуалок. Т.е. с админа снимаются постоянные просьбы типа «виртуалка повисла на перезагрузке, просьба сделать force reboot». Но есть у него одна подлянка. Гипервизоры обычно сидят в сети управления без доступа во внешний мир, а эта зараза может работать только с гипервизорами напрямую — везде в интерфейсе жестко зашиты их адреса, т.е. даже проброс портов не поможет. Но есть сторонний бесплатный вариант без этих ограничений — xvp. Честно говоря мы его не пробовали, т.к. необходимость пропала.
Ну и дальше по мелочи.
Косяк с бубунтой лечится без консоли, просто используем network install и указываем урл.
Плюс не совсем понял на фига использовали таких зверей, как 3850. Вместо четырех серваков лучше бы BaldeCenter взяли и набили их лезвиями в конфигурации типа Foundation for Cloud. И с дисками SSD, а то все брендовое железо и так любит долго стартовать, а тут хоть чуть-чуть время загрузки гипервизора сократите :)
Про WSS мы и пытались подчеркнуть эту же мысль, что он не позволяет решать многие админские задачи и очень ограничен в функциональности.
BladeCenter — хорошая штука. Сталкивались с модульными системами на примере Crossbeam — есть в этом свои особенности. Решили остановиться на отдельных серверах из-за большей гибкости.
BladeCenter — хорошая штука. Сталкивались с модульными системами на примере Crossbeam — есть в этом свои особенности. Решили остановиться на отдельных серверах из-за большей гибкости.
Ну по поводу гибкости я бы поспорил. У вас всего 4 сервера, а заняли почти полностью весь шкаф. Хотя вы и так себе отрезали путь к расширению за счет отсутствия коммутатора FC. Дальше расширяться только с покупкой 1-2 коммутаторов. И в шкафу останется место еще под максимум 1 сервер.
С системами, подобными BC, вы бы те же вычслительные мощности уместили в половину шкафа и еще бы имели свободными корзины под 6-10 серверов.
С системами, подобными BC, вы бы те же вычслительные мощности уместили в половину шкафа и еще бы имели свободными корзины под 6-10 серверов.
Ох не сказал бы что HS22, что стоят в моем BCH, стартуют быстрее rack'овых серверов… Пока UEFI проинициализируется, FC, IB — проходит ого-го сколько времени :)
Не, с железом явно не подумали. Зачем оптику 10G кидать в пределах шкафа? Это же по SFP+ на каждый конец, плюс кабель. Дешевле кабели DAC — у них с каждого конца по SFP+, между ними медь, длина обычно 1,3 и 5 метров (вроде еще 10 бывают в природе).
Сервера напрямую в систему хранения включать? «Безумству храбрых.....». Вылетит один контроллер в системе хранения и досвидос половина облака пока замена не приедет. А дохнуть эти редиски любят значительно чаще коммутаторов, точнее говоря коммутаторов пока дохлых не встречал, а контроллеры менял неоднократно.
Сервера напрямую в систему хранения включать? «Безумству храбрых.....». Вылетит один контроллер в системе хранения и досвидос половина облака пока замена не приедет. А дохнуть эти редиски любят значительно чаще коммутаторов, точнее говоря коммутаторов пока дохлых не встречал, а контроллеры менял неоднократно.
Из-за этой же экономии на коммутаторе уполовинили скорость каждому серваку — второй сосок в картах FC свободный висит… :(
А что мешает каждый сервер на два контроллера СХД повесить? У нас полка SAS, именно так и сделано. Т.е. на каждом серванте два SAS-HBA, каждый смотрит одним линком в отдельный контроллер СХД.
В данном случае мешает наличие всего 2 портов на каждом контроллере системы хранения. То есть их там суммарно по количеству серверов :(
Надо было брать полку SAS, скорость 6Gb, 4 входа на каждом контроллере, позволяет подключать 4 сервера с дублированием линков или 8 серверов без дублирования. Много раз встречал упоминания про SAS-коммутаторы, которые позволяют строить небольшие сети SAN на SAS, длина кабеля — 20 метров. Стоимость такого коммутатора от LSI — 2000$. Стоимость SAS-контроллера для полки раза в два дешевле, чем FC. FC в Вашем случае явно перебор.
Не в моем, а в случае автора статьи.
По поводу SAN на SAS подробно обсуждали в комментах здесь: habrahabr.ru/company/oblakoteka/blog/177047/
Я бы сказал, что это только для небольших систем. В случае крупной инфраструктуры цена FC уже не так принципиальна.
Но в случае топикстартера SAS HBA хватило бы за глаза.
По поводу SAN на SAS подробно обсуждали в комментах здесь: habrahabr.ru/company/oblakoteka/blog/177047/
Я бы сказал, что это только для небольших систем. В случае крупной инфраструктуры цена FC уже не так принципиальна.
Но в случае топикстартера SAS HBA хватило бы за глаза.
У Вас серьёзный косяк с топологией. Если выходит из строя один СХД-контроллер, Вы теряете половину хостов Xen. Что будете делать в данной ситуации?
при выходе из строя сервера мы потеряем все виртуальные машины, которые были на нём. Также такой подход сильно усложняет задачу балансировки нагрузки, потому что миграция виртуальной машины потребует перемещения её диска на другой сервер, а это — достаточно долгий процесс. Поэтому в нашем стенде используется внешнее хранилище DELL md3620f
т.е. если у вас раньше ломался 1 сервер вы теряли половину машин и могли запустить резервные вм которые реплицровались на втором хосте, то сейчас если ломается DELL md3620f, вы наверно будете в шоколаде?
Или я не внимательно прочитал и у вас два хранилища с репликацией?
т.е. если у вас раньше ломался 1 сервер вы теряли половину машин и могли запустить резервные вм которые реплицровались на втором хосте, то сейчас если ломается DELL md3620f, вы наверно будете в шоколаде?
Или я не внимательно прочитал и у вас два хранилища с репликацией?
Всё правильно. Основная проблема у нас была именно с балансировкой нагрузки. Запускается одновременно много ВМ, и удобнее, если они все хранятся в едином месте, чтобы не перемещать и их между локальными дисками серверов.
В той схеме которая у нас реализована, узким местом является именно хранилище. Сейчас есть RAID для защиты от выхода из строя дисков. Защита от выхода из строя хранилища решается через репликацию, но нужно ещё хранилище. Со временем придём к этому, а вместе с этим перейдём и на оптический коммутатор.
В той схеме которая у нас реализована, узким местом является именно хранилище. Сейчас есть RAID для защиты от выхода из строя дисков. Защита от выхода из строя хранилища решается через репликацию, но нужно ещё хранилище. Со временем придём к этому, а вместе с этим перейдём и на оптический коммутатор.
А можно узнать ценник? Т.е. можно собрать подобное облако «на коленке», используя платформы от Intel и хранилища от Supermicro, такой подход будет иметь много минусов, но одним из плюсов будет цена. Используя вендорное железо, мы получаем плюсы в поддержке и некой ментальной надежности (да и вообще, это же «ынтырпрайз»), но ценник будет совершенно иным. Собственно и интересно — сколько в конечном счете стоит такая стоечка (если можно, то с детализацией)?
Думаю, при виде этой цифры многие матерят своё «место работы» :)
Но все равно без второго хранилища я бы не рискнул бы что-то делать в рабочей среде.
Слышал случаи когда ломалась единственная схд, слесари использовали попку админа как пневмо-кусачки для перекусывания ломиков!
Кто лично знает такие истории отзовитесь ;)
Но все равно без второго хранилища я бы не рискнул бы что-то делать в рабочей среде.
Слышал случаи когда ломалась единственная схд, слесари использовали попку админа как пневмо-кусачки для перекусывания ломиков!
Кто лично знает такие истории отзовитесь ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Облако с нуля с использованием XenServer