Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 104
Один физический сервер на атоме. Индекс 1.0
ПС
Он кстати выдерживал хабраэффект, когда брат тут статью печатал)
ПС
Он кстати выдерживал хабраэффект, когда брат тут статью печатал)
Неужели кому-то действительно надо объяснять преимущества виртуализации?
А виртуальных хостов сколько? (картинки не грузятся, а вашу математику я не осилил — получается, что при текущем V-Index, равным 99%, ваш серверный парк вырос радикально)
При этом физических серверов осталось всего 3
А виртуальных хостов сколько? (картинки не грузятся, а вашу математику я не осилил — получается, что при текущем V-Index, равным 99%, ваш серверный парк вырос радикально)
Перезалил фото, увсе видно. Про преимущества, поверьте — многим надо объяснять и разжевывать.
Преимущества может и не надо, но объяснить как бороться с явными недостатками или убедить, что это не недостатки, а фичи — надо. А, главное, что в целом это будет выгодно.
Вот есть (арендуются) десяток серверов, слабеньких, стареньких, по сути десктопов, которые теоретически легко перенести на один современный и даже не топовый и выйдет дешевле. Но случись что с железом — упадут все 8 (2 — почти чисто резервные). Не было в инфраструктуре единой точки отказа, а с появлением виртуализации появится. Брать два современных, отводя один на резерв — дорого. Брать один современный а из существующих делать резервные — тоже не дешево, да и профит особо не понятен.
Вот есть (арендуются) десяток серверов, слабеньких, стареньких, по сути десктопов, которые теоретически легко перенести на один современный и даже не топовый и выйдет дешевле. Но случись что с железом — упадут все 8 (2 — почти чисто резервные). Не было в инфраструктуре единой точки отказа, а с появлением виртуализации появится. Брать два современных, отводя один на резерв — дорого. Брать один современный а из существующих делать резервные — тоже не дешево, да и профит особо не понятен.
Да, фич много. Расскажу про одну.
Обновление ПО. Как я бывало запаривался узнавать в последний момент что в 2-3-10 филиалах, где обслуживание только удаленное, не обновился flash плеер, необходимый для проведения вэбинара или любой другой софт. Просто мрак был, куча потерянного времени (да, чтоял sccm. но при большой гетерогенной сети он не всегда был эффективен). Теперь обновление занимает минуты, обновил мастер образ, протестировал — вот оно и счастье!
Обновление ПО. Как я бывало запаривался узнавать в последний момент что в 2-3-10 филиалах, где обслуживание только удаленное, не обновился flash плеер, необходимый для проведения вэбинара или любой другой софт. Просто мрак был, куча потерянного времени (да, чтоял sccm. но при большой гетерогенной сети он не всегда был эффективен). Теперь обновление занимает минуты, обновил мастер образ, протестировал — вот оно и счастье!
Честно говоря не понимаю о чём речь. Как я представляю виртуализацию: есть куча образов дисков, для каждого виртуального хоста как минимум один образ диска, а гипервизор обеспечивает запуск ос с этих образов так, чтобы ось думала, что у неё отдельный хост и диск. Гипервизор тупо не знает какой образ соответствует какой оси (в смысле конкретному дистру/версии), он а на каком-то самом низком уровне перехватывает обращение гостевой оси к железу, так чтобы она думала что всё железо в её монопольном распоряжении.
Ну честно говоря не представляюю какие плюсы в плане обновления, если на 2 серваках стоит win 2k3, на 2 CentOS (на этих 4-х хоть версии синхрониированы), а на остальных шести Debian и Ubuntu различных релизов. Тупо: работает — не трогай.
Ну честно говоря не представляюю какие плюсы в плане обновления, если на 2 серваках стоит win 2k3, на 2 CentOS (на этих 4-х хоть версии синхрониированы), а на остальных шести Debian и Ubuntu различных релизов. Тупо: работает — не трогай.
Плохо значит Вы представляете виртуализацию. Есть виртуализация серверов / рабочих станций / приложений. В описанном мной примере речь идет о VDI виртуализации ( виртуализация рабочих столов ) ну как, это в + или -. Попробуйте за 30 минут развернуть пол тысячи рабочих мест.
У меня мысль прежде всего о серверах. И даже если о рабочих станциях, то я не представляю чем тут может виртуализация помочь. Одному девелоперу нужны виндовские продукты, а другому линуксовые, хотя задача у них стоит одна — разработка демона FreeBSD на Python. А вариант подключить 1000 сессий к консоли OS/2 Я нормальной виртуализацией не считаю. Виртуализация с большой буквы для меня значит Virtual Server как минимум, над которым я могу, как администратор инфраструктуры, управлять что на него загрусится, какая-нибудь винда, фряха или линь.
VDI, конечно, штука модная, но в современных реалиях и в больших масштабах миграция на тонких либо нулевых клиентов — это ОЧЕНЬ дорого, и очень редко когда целесообразно. Обычно все-таки виртуализируют отдельные приложения.
ИМХО, как раз в больших масштабах и появляется целесообразность и адекватность затрат.
Хотя последнее время всё чаще слышу, что небольшие компании (на 20-30 машин) пробуют пересаживать на виртуалки и «допиливанием» компонент доступа и минимальной автоматизации развёртывания.
Хотя последнее время всё чаще слышу, что небольшие компании (на 20-30 машин) пробуют пересаживать на виртуалки и «допиливанием» компонент доступа и минимальной автоматизации развёртывания.
VDI требует колоссальных ресурсов памяти, дисков (IOPS в первую очередь). Тонкие клиенты (HP например) по цене сравнимы с обычными компьютерами, а со всеми лицензиями куда дороже. Требования к качеству работы сети повышаются, как и нагрузка на нее, соответственно — больше надо платить провайдерам. Проблемы на сети полностью нарушают работоспособность компьютеров, т.е. нельзя даже в екселе что-то там поделать, дожидаясь восстановления доступа к файловым серверам.
А вот конкретных преимуществ по сравнению со стандартизированной конфигурацией аппаратного и программного обеспечения на пользовательских рабочих местах (т.е. четкая и предсказуемая работа SCCM) не вижу вообще.
А вот конкретных преимуществ по сравнению со стандартизированной конфигурацией аппаратного и программного обеспечения на пользовательских рабочих местах (т.е. четкая и предсказуемая работа SCCM) не вижу вообще.
1. Требования к СХД, согласен, повышаются. Как и общее требование к надёжности всей системы, но это неотъемлемое следствие консолидации. Серверной в том числе. Вы же не станете кучу своих серверов виртуализировать на старом недублированном железе? Так и здесь.
2. Цены на тонкие клиенты — при больших объёмах могут быть совсем другие. Но на самом деле, перейти сразу всем на ТК — в наших реалиях действительно фантастика. Почти все успешные крупные или не очень внедрения, которые я слышал проходили по формуле: текущие старые компы превращаем в точки доступа. Сломался — меняем на ТК. Таким образом затраты чуть более равномерно распределяются на 2-3 года.
3. VDI — это только про LAN. Доступ из WAN, как в случае с VPN: реализуем, но скорее всего нужен только части сотрудников. Если обоснованно нужна мобильность пользователя, то это уже не ТК и есть всякие Local mode и Xen Client.
4. Преимущество в безопасности, в сокрытие ИТ-работы от ваших подльзователей (не сталкивались с потоком звонков «довольных» пользователей при накатывании очереного SP?), в гибкой настройке типов рабочих дескоторв (колл-центры в 400-800 человек во всяких телекомах), элементарнрое и удобное разворачивание учебных классов, хоть каждый день и т.п.
Ещё раз, VDI — это не панацея, и вцелом, для ресурсов 20-30, даже 100 рабочих мест, ломать уже существующие схемы работы и городить новый огород действительно не всегда обосновано.
2. Цены на тонкие клиенты — при больших объёмах могут быть совсем другие. Но на самом деле, перейти сразу всем на ТК — в наших реалиях действительно фантастика. Почти все успешные крупные или не очень внедрения, которые я слышал проходили по формуле: текущие старые компы превращаем в точки доступа. Сломался — меняем на ТК. Таким образом затраты чуть более равномерно распределяются на 2-3 года.
3. VDI — это только про LAN. Доступ из WAN, как в случае с VPN: реализуем, но скорее всего нужен только части сотрудников. Если обоснованно нужна мобильность пользователя, то это уже не ТК и есть всякие Local mode и Xen Client.
4. Преимущество в безопасности, в сокрытие ИТ-работы от ваших подльзователей (не сталкивались с потоком звонков «довольных» пользователей при накатывании очереного SP?), в гибкой настройке типов рабочих дескоторв (колл-центры в 400-800 человек во всяких телекомах), элементарнрое и удобное разворачивание учебных классов, хоть каждый день и т.п.
Ещё раз, VDI — это не панацея, и вцелом, для ресурсов 20-30, даже 100 рабочих мест, ломать уже существующие схемы работы и городить новый огород действительно не всегда обосновано.
1. Речь именно про ресурсы.
И возрастают требования к надежности слабо контролируемых провайдерских каналов — от пользователя до хостов. А ведь где-то нельзя завести каналы через разных ОПМ, где-то найдется точка пересечения каналов от разных провайдеров и ОПМ (и она, разумеется, рано или поздно сбойнет), и так далее.
2. Само собой. Только все равно дорого выходит. И по лицензиям, и по железу. Куда дороже, чем с толстыми клиентами.
3. То есть любой компании, у которой ЦОДы находятся далеко от всех пользователей (наиболее типичный случай), уже не следует всерьез внедрять VDI? Или надо тянуть свою оптику по разным трассам?
Разумеется, полная виртуализация рабочего места нужна не всем. Даже скорее не нужна практически никому…
4. Безопасность — не факт (есть много способов огородить и толстого клиента). Проблемы после апдейта и там, и там вылезут у многих, и такие проблемы решаются вовсе не удалением сервиспака, а более точечно (и нет, у нас никогда не было связанных с апдейтами серьезных проблем, ибо — унификация рабочих мест и сильно упрощенное благодаря этому тестирование).
Колл-центры на тыщу человек и у меня есть. Никто ни разу не смог доказать, что с тонкими клиентами операторам будет лучше, чем с текущей схемой виртуализации отдельных приложений. А уж сколько разных связанных с гарнитурами проблем вылезало…
С QoS печалька. Вроде ни одна реализация VDI не обеспечивает раздельную маркировку голосового трафика, видеотрафика и трафика приложений. А последние два ведут себя куда нестабильнее, чем голос. То есть с софтофонами возникает проблема, которую непонятно как решать.
А для большего количества рабочих мест совсем нецелесообразно.
И возрастают требования к надежности слабо контролируемых провайдерских каналов — от пользователя до хостов. А ведь где-то нельзя завести каналы через разных ОПМ, где-то найдется точка пересечения каналов от разных провайдеров и ОПМ (и она, разумеется, рано или поздно сбойнет), и так далее.
2. Само собой. Только все равно дорого выходит. И по лицензиям, и по железу. Куда дороже, чем с толстыми клиентами.
3. То есть любой компании, у которой ЦОДы находятся далеко от всех пользователей (наиболее типичный случай), уже не следует всерьез внедрять VDI? Или надо тянуть свою оптику по разным трассам?
Разумеется, полная виртуализация рабочего места нужна не всем. Даже скорее не нужна практически никому…
4. Безопасность — не факт (есть много способов огородить и толстого клиента). Проблемы после апдейта и там, и там вылезут у многих, и такие проблемы решаются вовсе не удалением сервиспака, а более точечно (и нет, у нас никогда не было связанных с апдейтами серьезных проблем, ибо — унификация рабочих мест и сильно упрощенное благодаря этому тестирование).
Колл-центры на тыщу человек и у меня есть. Никто ни разу не смог доказать, что с тонкими клиентами операторам будет лучше, чем с текущей схемой виртуализации отдельных приложений. А уж сколько разных связанных с гарнитурами проблем вылезало…
С QoS печалька. Вроде ни одна реализация VDI не обеспечивает раздельную маркировку голосового трафика, видеотрафика и трафика приложений. А последние два ведут себя куда нестабильнее, чем голос. То есть с софтофонами возникает проблема, которую непонятно как решать.
для ресурсов 20-30, даже 100 рабочих мест, ломать уже существующие схемы работы и городить новый огород действительно не всегда обосновано.
А для большего количества рабочих мест совсем нецелесообразно.
ресурсы несомненно дорогие. но как и с SSD со временем они только дешевеют, каналы связи тоже только дешевеют. на пользователя достаточно 250К. а если использовать NetScaler то на 500 пользователей xendesktop хватает 50 Mb. по ценам СПб для корпоративных клиентов — это порядка 15 т.р. в мес
ресурсы несомненно дорогие. но как и с SSD со временем они только дешевеют
Но одновременно с этим растут требования к этим самым ресурсам, так что по факту удешевления не будет ;)
по ценам СПб для корпоративных клиентов — это порядка 15 т.р. в мес
Интернет до колл-центра? А что это такое? Никогда не слышал… Я знаю только провайдерский MPLS VPN или любой из видов L2VPNа. Они стоят дороже, чем 15к в месяц, и в любом случае надо любую цифру помножать на 2 или 3, ведь нельзя же без резервирования колл-центр оставить. А переподписка в плане задействования в пике более чем 50% суммарной емкости двух каналов недопустима по причине сложностей с QoS (если один канал упадет — мгновенно упремся в емкость оставшегося, и прощай, голос).
У меня 32.
Только эта цифра практически ни чего не значит.
Только эта цифра практически ни чего не значит.
у меня ноутбук и 4 виртуалки: О
>Выход оборудования из строя стал повторяться с периодической постоянностью
Не совсем понял суть… после виртуализации всё железо у вас стало абсолютно надёжным?
Как я понял, у вас теперь появились единые точки отказа (SPF), как решается вопрос резервирования на уровне железа?
Не совсем понял суть… после виртуализации всё железо у вас стало абсолютно надёжным?
Как я понял, у вас теперь появились единые точки отказа (SPF), как решается вопрос резервирования на уровне железа?
Оборудование полностью задублтрованно, а точнее задублированны все компоненты в системе, от контроллеров до SFP
как может быть дублирование SFP? на то она и SFP что она не дублирована О_О
пс. простите за идиотский вопрос, у Вас везде написано «задублтрованно» или «дублтрования», это удачный копи\пейст или ...?
пс. простите за идиотский вопрос, у Вас везде написано «задублтрованно» или «дублтрования», это удачный копи\пейст или ...?
сам пишу, сказывается тройка по русскому. прошу строго не судить
да этож шутка, Вы лучше про SFP объясните. если я правильно понимаю SFP — Single Point of Failure, как она может быть дублирована?
Я под SFP понимал sfp модули. Если обратите внимание на последнею картинку, той поймете что решение построено на Blade серверах. (в моем случае — у них задублированы все компоненты). Конечно есть компонент который не имеет 100% резервирования, как в поговорке — «кто бросил сапиги на пульт управления» — это персонал. По жедезу — 100% дубляж.
SFP (англ. Small Form-factor Pluggable) — промышленный стандарт модульных компактных приёмопередатчиков (трансиверов), используемых для передачи данных в телекоммуникациях.
А в чем единая точка отказа в данном случае? Я, конечно, не вижу какая точно конфигурация, но как минимум доступ к СХД должен выполняться с использованием двух контроллеров, а VMware обеспечить миграцию виртуальной машины в случае поломки блэйда. Если все правильно приобретено и настроено, выход из строя любого компонента не должно повлиять на работоспособность системы в целом.
На текущий момент 50/50, но все уходит в облака, поэтому после нового года по факту из серверов останется только домен, да сервер печати)
Думаю в перспективе, эту стойку просто перенесем в data центр или аналогичные ресурсы возьмем в аренду для дублтрования мощьностей
Francyz, поделись по каким критериям переходишь в облако?
Мы решили сократить затраты на содержание серверов + уменьшение лицензии от мелкомягких. У нас все сервисы завязаны на них, поэтому переход вариантов не много, сейчас идем на O365. Там будет связка Lync + Sharepoint + Exchange. Доступ к сервисам из любой точки страны.
Да и подобный переход снимает часть ответственности за сохранность данных и перекладывает их на принимающую сторону,
Если интересует какая-то конкретная ситуация или вопрос, то спросите, попробую ответить )
Да и подобный переход снимает часть ответственности за сохранность данных и перекладывает их на принимающую сторону,
Если интересует какая-то конкретная ситуация или вопрос, то спросите, попробую ответить )
А кто занимался внедрением у вас? Кто смог обосновать переход на виртуализацию? Ведь это далеко за миллион стоит, а профита первоначально никакого, руководство обычно не вдохновляется от таких изменений.
Внедрением занимались самостоятельно. Интеграторы не привлекались, т.к. предложенная цена внедрения была просто заоблачной. Единственное чем помогал поставщик техники — установил Blade корзину в стойку.
+1, получается что для виртуализации купили кучу брендового железа, блейды, все такое. Но ведь можно было бы профита добиться и другим путем, заменив десктопы с первой фотки на самосборные серваки и поставив хороший кондиционер, а виртуализация тут уже как бы сбоку, можно использовать, а можно и нет.
Ну я не совсем это хотел сказать. То что показано на фотографии — прекрасная конфигурация, я вижу четыре 4-х процессорных лезвия, пять 2-х процессорных (исходя из формфактора только), большой и быстрый дисковый массив.
При верной настройке эта конфигурация обеспечивает очень гибкую производительность, легкость миграции и очень высокую устойчивость сервисов, легкость масштабирования.
Я не ставил под сомнение необходимость виртуализации, мне просто интересно как это было обосновано так как преимущества обычно видит только администратор и в финансовые преимущества будет выливаться только если компания продолжает развиваться и расти и ей интересно иметь надежную инфраструктуру.
При верной настройке эта конфигурация обеспечивает очень гибкую производительность, легкость миграции и очень высокую устойчивость сервисов, легкость масштабирования.
Я не ставил под сомнение необходимость виртуализации, мне просто интересно как это было обосновано так как преимущества обычно видит только администратор и в финансовые преимущества будет выливаться только если компания продолжает развиваться и расти и ей интересно иметь надежную инфраструктуру.
Могли бы и описать, какие именно преимущества виртуализации подтвердились на вашем опыте, какие нет.
Самое сложное оказалось с аппаратными ключами защиты. Тут решений много, от програмного проброса внутрь ВМ до аппаратных USB то Lan коммутаторов.
Самое интересное в таких проектах — это то, что моло компаний и системных интеграторов которые производят полный сайзинг мощьностей для будущей инфраструктуры. Сайзинг по CPU / RAM / HDD — тут никаких вотросов нет, взял калюкулятор и посчитал. По моему опыту могу сказать, про IOPS все забывают!!! Считаю, что переход нужно начинать именно с расчетов IOPSов.
И местами горький опыт лишь подтвердил мои догадки. А так все просто, за время написания коментария создал еще 2 виртуальные машины.
Самое интересное в таких проектах — это то, что моло компаний и системных интеграторов которые производят полный сайзинг мощьностей для будущей инфраструктуры. Сайзинг по CPU / RAM / HDD — тут никаких вотросов нет, взял калюкулятор и посчитал. По моему опыту могу сказать, про IOPS все забывают!!! Считаю, что переход нужно начинать именно с расчетов IOPSов.
И местами горький опыт лишь подтвердил мои догадки. А так все просто, за время написания коментария создал еще 2 виртуальные машины.
Наш переход в СХД как раз ограничен IOPS, сейчас особо требовательное хранилище находится на физическом сервере в виде SSD дисков, если делать это на внешнем хранилище, то это будет стоить уже на порядок дороже, а старые SSD уже по назначению использовать не получится. Но риск отказа, конечно, повышается.
Поделитесь требованиями в IOPS что СХД не справляется? EVA справляется, хотя еще 3 полки собираемся докупить для уведичения производительности.
До 2000 операций доступа к диску, судя по монитору.
Так скажем, до ssd дисков использовался 10-ый рэйд из sas 15к дисков, производительность БД не удовлетворяла, после перехода на ssd стало все значительно веселее.
EVA по идее должна справиться с таким требованием, однако EVA стоит, на сколько я помню, не маленьких денег, а стоимость одной единицы данных и во все зашкаливает. По этому ищется некий компромисс цены, надежности, производительности, масштабируемости. И главное, есть проблемы с методикой тестирования. Покупать кота в мешке ни кто не будет и до покупки нужно четко представлять, покроет эта система наши потребности или нет.
Так скажем, до ssd дисков использовался 10-ый рэйд из sas 15к дисков, производительность БД не удовлетворяла, после перехода на ssd стало все значительно веселее.
EVA по идее должна справиться с таким требованием, однако EVA стоит, на сколько я помню, не маленьких денег, а стоимость одной единицы данных и во все зашкаливает. По этому ищется некий компромисс цены, надежности, производительности, масштабируемости. И главное, есть проблемы с методикой тестирования. Покупать кота в мешке ни кто не будет и до покупки нужно четко представлять, покроет эта система наши потребности или нет.
Сильно советую закопать EVA посмотреть на NetApp c Flash Cache или Flash Pool, на крайний случай.
Мне видится, что это неплохая точка оптимума в отношении «цены, надежности, производительности, масштабируемости».
Плюс еще много всяческих плюшек в области виртуализации.
Мне видится, что это неплохая точка оптимума в отношении «цены, надежности, производительности, масштабируемости».
Плюс еще много всяческих плюшек в области виртуализации.
Обсуждали NetApp, но выходит достаточно дорого, плюс мне было сказано, что на каждый контроллер отжирается по 3 целых диска, то есть дисков надо покупать много, иначе утилизация невероятно высокая и цена может выйти миллиона в два, это только на СХД что бы покрыть текущие потребности по хранению данных.
плюс мне было сказано, что на каждый контроллер отжирается по 3 целых диска
Ну нет, это не так, конечно. Это вам либо некомпетентный человек сказал, либо вы его неправильно интерпретировали. В настоящий момент на служебную директорию рекомендуется отвести порядка 150GB, причем в настоящий момент у меня она на 95% пуста (я в нее валю всякий неценный шит, типа дистрибутивов). Место нужно «на всякий случай», если вдруг контроллер начнет валиться в core dump и ему для отладки эьти дампы надо будет куда-то сложить. Можно сделать служебный том «тонким», тогда он будет занимать ровно то, сколько в нем данных. Сейчас на моей 2040 это: 4.54 GB (4,885,688,320 bytes)
Это все, весь служебный том.
Обсуждали NetApp, но выходит достаточно дорого
Это недешево, да, но вопрос, что вы получаете за ваши деньги. Если бы все измерялось только ценой, то все бы ездидли на вазовской классике, ведь это автомобиль, он ездит, и стоит дешевле всех других автомобилей на рынке. :)
В тех случаях, когда фичи становятся важнее, начинает играть роль «фичастость».
Если у стораджа X вы за Y денег получаете Z полезных фич, а у стораджа X' за 1,5х Y денег получаете 4х Z полезных фич, то сторадж X' может оказаться выгодным приобретением.
иначе утилизация невероятно высокая и цена может выйти миллиона в два
Вот у меня, например, на уже упомянутой 2040, которая вообще позавчерашний день, на одной полке дисков, заполненной томами виртуальных машин примерно на 40%, величина дедупликации составляет около 35%. Это при том, что для обеспечения эффективности и оптимальности дедупликации не делалось вообще ничего, тупо свалили три десятка виртуалок на NetApp и включили дедупликацию.
35% означает, что по сравнению с такой же системой без дедупликации диски обошлись нам на треть дешевле, так как данных на них поместилось на 35% больше.
А если сделать по уму, то получить результат в 65-75% — довольно тривиально.
Это тоже стоит учитывать в расчете цены.
По поводу утилизации я тоже очень удивился. Я переспросил, что точно ли 3 диска с каждого контроллера занимается? Да, говорят, 3 первых диска на каждый контроллер, всего 6 дисков на 2 контроллера. Мол, куда же ему, по вашему, снэпшоты класть и файлы конфигурации?
Ну, можно считать, что меня ввели в заблуждение.
По поводу рисков это все понятно. Однако это было бы верно, если в компании кто-то мог считать стоимость рисков. А так в компании во всю процветает Великий Русский подход к бизнесу и пока проблема не случится, предпринимать ничего не хотят, тем более то, что не приносит прямой выгоды.
Еще по NetApp пугали, что бандлы вполне могут быть не расширяемыми и заполненные дисками уже имеют свой предел и это зашито в устройстве.
И мне не предлагали такой бандл, как вы показали, максимум что предлагали это 12 дисков и все. Например, двухконтроллерная конфигурация 2040 12х600GB была предложена примерно за 30k$.
Ну, можно считать, что меня ввели в заблуждение.
По поводу рисков это все понятно. Однако это было бы верно, если в компании кто-то мог считать стоимость рисков. А так в компании во всю процветает Великий Русский подход к бизнесу и пока проблема не случится, предпринимать ничего не хотят, тем более то, что не приносит прямой выгоды.
Еще по NetApp пугали, что бандлы вполне могут быть не расширяемыми и заполненные дисками уже имеют свой предел и это зашито в устройстве.
И мне не предлагали такой бандл, как вы показали, максимум что предлагали это 12 дисков и все. Например, двухконтроллерная конфигурация 2040 12х600GB была предложена примерно за 30k$.
Мол, куда же ему, по вашему, снэпшоты класть и файлы конфигурации?
О, какая жесть :)
Нет, это неправда. Правда — выше :)
Но у меня есть подозрение, что вы все же неправильно интерпретировали. Дело в том, что на контроллер действительно от общего объема raw-данных купленных дисков отнимается емкость трех дисков на контроллер: два уйдут на double parity и один на обязательный spare.
Это плата за надежность, за RAID.
С другой стороны когда у вас на RAID-10 на это же самое уходило половина всех дисков, это же не вызывало такого протеста?
Еще по NetApp пугали, что бандлы вполне могут быть не расширяемыми и заполненные дисками уже имеют свой предел и это зашито в устройстве.
Это «и так и не так».
Это так, потому что для конкретной модели действительно определен потолок по количеству дисков. Но он вообзе-то достаточно высок. Например для самой младшей на сегодня в линейке 2220 это 144 диска.
Это не так, потому что расширяемость для NetApp очень простая. Если вы переросли данную модель по числу дисков, то просто меняется контроллер на более мощную модель, и на тех же дисках, без миграции, без смены софта, без бэкапа и рестора, Замена контроллера — примерно минут 20 с перекуром, после чего система поднимается с теми же данными и новым контроллером. Такое, наскольно я знаю, не умеет больше никто. А это, кстати, именно потому что «индивидуальность» данной системы хранится отдельно от контроллера, на дисках служебного тома.
Насколько 144 диска в самой младшей модели это лимит для вашего применения — решайте сами. ПО моему опыту меняют контроллеры не потому что уперлись в число дисков, а потому чо уперлись в производительность. Так что это ограниченое оно довольно таки теоретическое.
И мне не предлагали такой бандл
Дык торговаться надо, там ребята много куда могут упасть. ;)
Главный секрет тут умудриться купить сразу и разом, потому что потом цены на расширение полками уже не имеют той крутой скидки, как на покупку «счас» в составе готового стораджа.
Ну им в конце концов надо тоже на что-то жить :)
Я предлагаю тут перестать мусорить, а то сейчас прибегут борцы с пиаром, и сочтут что я кого-то опять пиарю :)
А, да, про миллиона два:
FAS2040 c 12 x SATA 1TB + 24 x SAS 450GB + all inclusive софта + 3 года сервиса Next Business Day + 3 года поддержки с кейсами = менее 50 тысяч USD
2040 уже не продается, но новые системы в аналогичном классе имеют схожие ценники.
FAS2040 c 12 x SATA 1TB + 24 x SAS 450GB + all inclusive софта + 3 года сервиса Next Business Day + 3 года поддержки с кейсами = менее 50 тысяч USD
2040 уже не продается, но новые системы в аналогичном классе имеют схожие ценники.
Сильно советую
… не для этой задачи.
Раз уж задача о переходе на новое оборудование будет стоять, предлагаю ознакомиться с новым анонсом HP StoreServ 7000 habrahabr.ru/company/hp/blog/161273
Получите ту же управлялку, тот же wide stripe между всеми дисками массива, бесплатно перенесете данные на более быстрый массив, еще много вкусностей бесплатно, а по ценнику — не дороже EVA.
Если будет интересно — можно рассчитать проект.
Покупать оборудование, которое только выпущено в свет, по которому еще нет опубликованных Best Practices и экспертизы, не поймано ни одного бага в прошивках и не выпущен «первый сервиспак», по которому еще не объявлены аудированные результаты бенчмарков (если они вообще проводились), не говорю уж о том, что не имеющих, например, дедупликации и unified storage, становящихся в данной области совершенно необходимыми — это либо для очень богатых (готовых, в случае неудачи выкинуть покупку и купить другую) или для очень храбрых (готовых провести бетатестинг своими силами).
которое только выпущено в свет
ПО уже протестировано и отлажено, версия 3.1.2 (никакая не 1.0b)
еще нет опубликованных Best Practices и экспертизы
Как раз есть, например concept guide: bizsupport2.austin.hp.com/bc/docs/support/SupportManual/c02986000/c02986000.pdf
не имеющих, например, дедупликации и unified storage
Имеющих, можно включить в спецификацию.
это либо для очень богатых
Это для midrange, несильно дороже EVA.
Для заказчиков: вместе со спецификацией могу согласовать звонок с заказчиками, которые ставили похожие решения и которые уже ждут поставки и будут разворачивать StoreServ 7000 в начале января 2013, чтобы послушать про массивы из «первых уст».
ПО уже протестировано и отлажено
Когда MS выпускает новую OS она тоже «протестирована и отлажена», тем не менее ни для кого не секрет, что вскоре после этого начинаются довольно «горячие деньки» у всех, кто ри скнет поставить релиз сразу же после выхода. Это реальность, нелепо это игнорировать.
Как раз есть, например concept guide:
Нет, я имел ввиду другое. Вот у NetApp, например, только по теме виртуализации есть добрых полтора десятка документов, это и Best Practices, и Deployment Guide, причем не только по VMware, например, но и по таким редким птицам, как KVM или OracleVM, не считая множества руководств по прикладным системам, базам данных, и прочему.
Значительная часть их даже переведена на русский.
Всего этого, насущно необходимого тем, кто берет такое развертывать, у HP просто нет.
Когда MS выпускает новую OS
В случае с Microsoft — иногда бывает очень серьезная работа от версии к версии, и изменения описываются в больших мануалах, меняются протоколы (ну, например, выход SMB 3.0 в последней версии, или изменения в Hyper-v). В случае с 3PAR — все релизы обязательно тестируются, работающий функционал из предыдущих версий сохранен. Да, и никто не заставляет ставить новые версии ПО — всегда можно работать на старых ;)
В случае покупки StoreServ 7000 — EVA никто забирать не будет, будет 180 дней бесплатной миграции. Даже если предположить, что будут какие-то ошибки в ПО (я такие случаи не припомню за ~5 лет), то заказчик перестрахован от потери данных.
у HP просто нет
Глупо так полагать. Это, все документы есть, по KVM и OracleVM тут их нет смысла выкладывать. Остальные — сброшу открытые ссылки, если найти не получится.
В случае с 3PAR — все релизы обязательно тестируются… Даже если предположить, что будут какие-то ошибки в ПО (я такие случаи не припомню за ~5 лет)… заказчик перестрахован от потери данных
Оптимизм — хорошая штука :)
То есть если ошибки есть, то это ошибки клиента, а не вендора? Хорошая позиция ;)
Это, все документы есть, по KVM и OracleVM
Да ладно? На только что выпущенную систему? Ну, ловлю на слове :)
Можно вопрос про дублирование. Где Вы храните образы виртуальных машин? Как организовано их дублирование?
Использу Veeam Backup (это не реклама) для снятия образов с ротацией. А про дублирование образов? а какой смысл?
Вы в одном из коментариев упомянули, что оборудование полностью задублтрованно. Оборудование, где хранятся образы тоже?
Я просто часто натыкаюсь на статьи об отказоустойчивых системах, в которых дублирование нод/heartbeat/миграции описаны достаточно подробно, а об отказоустойчивости nas, на котором хранятся образы VM или ничего или вскользь. Собственно вопрос, что происходит, когда отказывает nas.
Я просто часто натыкаюсь на статьи об отказоустойчивых системах, в которых дублирование нод/heartbeat/миграции описаны достаточно подробно, а об отказоустойчивости nas, на котором хранятся образы VM или ничего или вскользь. Собственно вопрос, что происходит, когда отказывает nas.
Чтобы отказала СХД — это надо очень постараться (не слышал про отказы EVAы уровня предприятия). В любом случае есть горячие образы (реплики ВМ на резервном СХД) + бэкапы па лентах
Чтобы отказала СХД — это надо очень постараться (не слышал про отказы EVAы уровня предприятия).
Батенька, да вы с CХД уровня предприятия похоже никогда не работали...:)…
Могу вам сказать точно, отказы СХД бывают у стораджей, независимо от их лейбла(XP ли это или EВА… неважно..).
Просто последствия бывают различными
Батенька, да вы с CХД уровня предприятия похоже никогда не работали...:)…
Могу вам сказать точно, отказы СХД бывают у стораджей, независимо от их лейбла(XP ли это или EВА… неважно..).
Просто последствия бывают различными
Лично я не встречался, и наверное это хорошо.
Я работал с схд разных классов от HP, даже сейчас есть «тестовая» P6000 и что я с ней не делал (у вендора волосы дыбом бы встали), для себя я сделал вывод — надо надеется на железо, иметь оперативный backup и «не бросать сапоги на пульт управления». С последним самый напряг.
Я работал с схд разных классов от HP, даже сейчас есть «тестовая» P6000 и что я с ней не делал (у вендора волосы дыбом бы встали), для себя я сделал вывод — надо надеется на железо, иметь оперативный backup и «не бросать сапоги на пульт управления». С последним самый напряг.
А чего про nas писать, там 2 контроллера, диски двух контроллерные. Выход из строя любого компонента СХД не вызывает отказ доступа к данным. Так что вероятность полного отказа дисковой системы очень невысокая.
у нас 75%. Не 100% т.к. не все можно засунуть в виртуальность. Например видео наблюдение, файловые сервера, нагруженный сервер баз данных. Короче все что имеет высокую нагрузку крутиться на реальном железе, а всякая мелочь в виртуальном окружении.
Я правильно понял, что KVM+XEN в сумме менее 1.6% рынка занимают? Мне с трудом в это верится.
У меня нет оснований не верить, индекс порказывает только «среднею температуру по больнице». Хоть температура и средняя, но положение дел отображает в полной мере.
Явный пример использования аналитических материалов компаний Microsoft и Vmware относительно функцианала своих гипервизоров и доли на рынке.
Явный пример использования аналитических материалов компаний Microsoft и Vmware относительно функцианала своих гипервизоров и доли на рынке.
Статья интересная) Но есть пара вопросов:
Какие продукты виртуализации используете?
Как сертифицируете свою инфраструктуру(если в этом есть необходимость)?
Какие продукты виртуализации используете?
Как сертифицируете свою инфраструктуру(если в этом есть необходимость)?
Не пойму: на фото блейд, довольно забитый серверами. На скрине hosts: 9. О каких трех серверах разговор? Я бы сказал, что (на глазок) на фоне старой серверной в новой даже больше хостов, просто они плотнее стоят.
Посчитайте — 9 лезвий и 3 заглушки. Про 3 физика, да они есть, но они рассредоточены, сервер backup — вообще максисально вынесен территориально от сетверной (чтобы бэкапы и данные не хронились в одном месте). Старая форка — это только половина, Вы не представляете что за бардак был за стойками, сбоку от них и т.д.
На самом деле Вы не обижайтесь, я удивился тому, что бросилось в глаза по тексту и по фото. Сам знаю, что бывает «за стойками».
Виртуалки — оно хорошо, главное, чтобы от них стало лучше и надежнее, посему, если так и есть — «так держать!» ;)
Виртуалки — оно хорошо, главное, чтобы от них стало лучше и надежнее, посему, если так и есть — «так держать!» ;)
Спасибо Александр, по какие могут быть «обиды». Просто вывесил 2 фото, что понимания масштабы бедствия ИТ подразделения, а за стойкими было просто не пройти даже. Почему-то на фото (возможно из-за вспышки) не было видно работающих лезвий, тык было бы понятно что из всего 9, 5 половинно размерных (1 тестовый) и 3 полноразмерный
Я доже про 3 сервера не мог врубиться. Фраза как-то неудачно получилась видимо. Думал было 30 физических хостов, а стало 3. А получилось, похоже, 9 хостов для виртуалок и 3 без виртуализации.
Зная «любовь» к локализованному софту, я бы не решился назвать датацентр «ЦОДом».
Андрей, респектифул респектед!
Увидел фотографии и сразу вспомнил свою серверную когда-то.
Конечно внедрение виртуализации в компанию огромный плюс. В серверной освобождается много места от наваленных системных блоков. Однажды моё терпение кончилось смотреть на висящую «мотню» и выйдя в выходной день переставил в стойках cisco с патч-панелями, заменил длинные провода короткими (30-50 см) патч-кордами.
У нас перевод серверов в виртуальную среду происходит постепенно (необходимо жалеть нервы финансового директора). Сначала один ESX, потом хранилище c fibre channel, на следующий год ещё две фермы и т.д.
Сервер управления виртуальной средой, это vCenter? Он стоит у нас на виртуальной станции. (даже если с ним что случится можно же используя vSphere Client подключиться напрямую к ESXi). Плюс ещё отключили службу VMware vCenter Orchestrator Configuration, а то сильно нагружала процессор и кушала много памяти.
Увидел фотографии и сразу вспомнил свою серверную когда-то.
Конечно внедрение виртуализации в компанию огромный плюс. В серверной освобождается много места от наваленных системных блоков. Однажды моё терпение кончилось смотреть на висящую «мотню» и выйдя в выходной день переставил в стойках cisco с патч-панелями, заменил длинные провода короткими (30-50 см) патч-кордами.
У нас перевод серверов в виртуальную среду происходит постепенно (необходимо жалеть нервы финансового директора). Сначала один ESX, потом хранилище c fibre channel, на следующий год ещё две фермы и т.д.
При этом физических серверов осталось всего 3 (один контроллер домена, backup сервер в которому подключена ленточная библиотека по SAS, сервер управления виртуальной средой (хотя и его я очень хочу виртуализировать для отказоустойчивости).
Сервер управления виртуальной средой, это vCenter? Он стоит у нас на виртуальной станции. (даже если с ним что случится можно же используя vSphere Client подключиться напрямую к ESXi). Плюс ещё отключили службу VMware vCenter Orchestrator Configuration, а то сильно нагружала процессор и кушала много памяти.
Сейчас это еще физика, но думаю что в скором времени (особенно при такой развернутой инфраструктуре) этот сервер становится очень уязвимым, слабое место. Конечно при выходе его из строя, особо критичного ничего не произойтдет, кластеры как работали — так и будут работать, но обеспечить его резервировнаие, бовабление памяти в случае необходимости в виртуальной среде проще. Конечно, как обычно тут мнение разделится, странно управление ВМ размещать на ВМ, но практика и опыт говорят об обратном
Угум-с, перечитали множество статей, сначала оставили системный блок как резервный (на всякий пожарный), а спустя полгода ушёл под другие нужды так и не пригодившись.
Один раз перезагрузив весь кластер и не достучавшись до vCenter испугались… оказалось в автозапуск забыли добавить.
P.S. моё мнение не нужен vCenter на полу, ему самое место в виртуализации со снапшотами.
Один раз перезагрузив весь кластер и не достучавшись до vCenter испугались… оказалось в автозапуск забыли добавить.
vmware-cmd /vmfs/volumes/f27f61fa-1c0f60ae/vCenter/vCenter.vmx start
P.S. моё мнение не нужен vCenter на полу, ему самое место в виртуализации со снапшотами.
А сеть в блейдах какая? Людимая HPшниками VirtualConnect?
На удивление не VC а FC. VC стоит огромных деньжишььььь, а по правильному модулей должно быть два, это еще больше стоит. Обошлись FC 8/16 8gb
«Не VC, а FC» — это все равно что «не теплое, а зеленое» :)
Вообще имхо, хорошо, что не VC. Товарищ рассказывал, что технари одного из довольно известных наших интеграторов громко ругаются на своих сейлов, когда они втюхивают VC покупателям. Да и у меня самого было несколько проблем с ним.
А ethernet-модули какие?
Вообще имхо, хорошо, что не VC. Товарищ рассказывал, что технари одного из довольно известных наших интеграторов громко ругаются на своих сейлов, когда они втюхивают VC покупателям. Да и у меня самого было несколько проблем с ним.
Обошлись FC 8/16 8gb
А ethernet-модули какие?
Ну думал что сокращенное fibre channel будет понятно))
В лезвиях стоят 10G но комутируемое оборудование всего 1G, может при нехватки пропускной способности и перейдем. Пока в транке хватает 3gb
В лезвиях стоят 10G но комутируемое оборудование всего 1G, может при нехватки пропускной способности и перейдем. Пока в транке хватает 3gb
У меня впечатление, что Вы немного не поняли, про что я. Может, Вы подумали про FCoE?
Вопрос был: стоят ли в Вашем Blade HP Virtual Connect-модули или стоят обычные «тупые» железки (брокада, циско)? Судя по картинке, я бы сказал, что стоят VC.
Вопрос был: стоят ли в Вашем Blade HP Virtual Connect-модули или стоят обычные «тупые» железки (брокада, циско)? Судя по картинке, я бы сказал, что стоят VC.
Я все понял и написал что стоят FC модули блокады 8/16. И полностью согласен с вашим высказыванием про то, что модули VC реально пытаются втюхать, причем разные интеграторы
Я все понял и написал что стоят FC модули блокады 8/16
Кроме FC-модулей никто не стоит? Синенькие и красненькие ethernet-патчкорды куда втыкаются?
Они идут в циску но она не модульная
В шасси они куда втыкаются?
Пасрушки. При наличии всего одной корзины и кучи свободных портов после отказа от старого зоопарка — вполне нормальное решение.
h18000.www1.hp.com/products/blades/components/ethernet/pass-thru/
«Они идут в циску»
Все в одну?
h18000.www1.hp.com/products/blades/components/ethernet/pass-thru/
«Они идут в циску»
Все в одну?
вот сюда, по предыдущей ссылке можно посмотреть что за зверь)
Сейчас вроде как принято считать отношение виртуальных ядер к физическим. При таком подходе у меня сейчас 3.3:1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Индекс виртуализации