Comments 54
Ожидал увидеть конфигурацию, где в результате будет кластер для iscsi target с storage spaces и все такое. А так ничего особенного, имхо.
Сколько стоила такая конфигурация, если не секрет? И в этом же ключе вопрос, неужели диски на 600GB стоят на столько дороже, что не смогли позволить их себе?
Сколько стоила такая конфигурация, если не секрет? И в этом же ключе вопрос, неужели диски на 600GB стоят на столько дороже, что не смогли позволить их себе?
Диски могли урвать на распродаже. Меня больше удивляет 4 диска в запасе, на Care Pack денег тоже не хватило или у HP такая плохая поддержка?
Каждый сервер обошелся в почти миллион рублей. На самом деле нам хватит, это железо работает в конторе 200 человек штатом. Ну и наша компания не платила за это ни копейки… Это то, что мы смогли обосновать и отстоять в определенных бюджетных рамках ген. подрядчику строительства…
Жесть. Вместо того, что бы купить 5-10 быстрых серверов, клиенту впаривается одна дорогущая медленная игрушка, а бедные офисные сотрудники потом сидят и плачут: какого хрена всё так медленно работает!
Большее издевательство над людьми — это сажать пользователей на терминальную винду. Сами то админы ей никогда не пользуются, потому что хорошо понимают, что это неработоспособно.
Большее издевательство над людьми — это сажать пользователей на терминальную винду. Сами то админы ей никогда не пользуются, потому что хорошо понимают, что это неработоспособно.
Кластер виртуальных машин и СХД — это модульность и гибкость. Его потом очень легко, удобно и дёшево расширять. А по поводу терминала — что именно Вам неудобно? Сейчас наблюдается общемировая тенденция в сторону виртуальных столов VDI и тонких клиентов. Это централизация ресурсов, обезличивание, экономия и т.п.
Пора «экономии» закончилась, и давно. Году эдак в '10-'12.
Кластеризация на винде — этой чистой воды маркетинг. Кто вам это «вкрутил» — памятник надо поставить, да еще и за такое бабло.
Недавно брали под кластер на 3 ноды (DL360 G8 на итаниумах c дублированными SAS и 96гиг RAM на каждом) с такой же СХД + «инклужа» — нам все обошлось в 3 ляма.
Для резервирования стораджа заюзали NetApp 2420 по акции, правда сейчас задумались — а для бэкапа ли… работает куда шустрее чем MSA.
Я извиняюсь, но вас где-то жестко накололи, ну или кто-то попилил. Холиваров поднимать не буду, но замечу, что виртуализация от MS ой как «еще не доросла».
PS / простите, промазал. Это ответ UrbanRider
Кластеризация на винде — этой чистой воды маркетинг. Кто вам это «вкрутил» — памятник надо поставить, да еще и за такое бабло.
Недавно брали под кластер на 3 ноды (DL360 G8 на итаниумах c дублированными SAS и 96гиг RAM на каждом) с такой же СХД + «инклужа» — нам все обошлось в 3 ляма.
Для резервирования стораджа заюзали NetApp 2420 по акции, правда сейчас задумались — а для бэкапа ли… работает куда шустрее чем MSA.
Я извиняюсь, но вас где-то жестко накололи, ну или кто-то попилил. Холиваров поднимать не буду, но замечу, что виртуализация от MS ой как «еще не доросла».
PS / простите, промазал. Это ответ UrbanRider
Спасибо за комментарий, узнал о неизвестных мне ранее продуктах, буду смотреть.
У меня в продакшене ESXi на бесплатных лицензиях, Микрофост мне тоже не нравится, но тем не менее Ваше заявление через чур категорично, в масштабах автора поста держать две ноды на Микрософте — почему бы нет?
Простите, в чем категоричность-то? Голые факты.
Если говорить об отказоустойчивости, то необходимо рассматривать все возможные модели отказа.
Экономии пора — закончилась. Особенно в вопросе виртуализации инфраструктур. Если кто-то застрял во времени — его право.
Единая СХД имеет смысл в составе кластера с поддержкой LM или HA как минимум. При Standalone-ахитектуре данный подход имеет мало смысла.
Опять-же, проброс USB у MS оставляет желать лучшего, а то, что поддерживает MS в качестве решения — стоит дорого и не гарнтировано работает, по заявлению тех же MS.
FailOver миграция машин гарантирована тольок с полным выключением, без выключения 50-80% машин выпадают в BSOD — печальная статистика.
API для резервирования VM, у MS все еще не готово, есть инструменты, но реализованы они не полностью и не покрывают всего списка потребностей при резервировании, и уж тем-более мало пригодны для гранулярного восстановления. Только избранные продукты и только в определенных конфигурациях, как то Exchange, AD, *SQL.
Я же не утверждаю, что MS не пригодно, я лишь хочу скахать, что оно пригодно, но довольно ограниченно. Если это перекрывает потребности — то не вижу никаких преград.
А по стоимости — тут, как-бы, ничего не буду комментировать — есть интернет, сайты, прайсы, руки и голова. Я выразил свое ИМХО, так как плотно занимаюсь железом HP, по долгу службы, и озвученные цены на конфигурации меня, мягко говоря, удивили.
Если говорить об отказоустойчивости, то необходимо рассматривать все возможные модели отказа.
Экономии пора — закончилась. Особенно в вопросе виртуализации инфраструктур. Если кто-то застрял во времени — его право.
Единая СХД имеет смысл в составе кластера с поддержкой LM или HA как минимум. При Standalone-ахитектуре данный подход имеет мало смысла.
Опять-же, проброс USB у MS оставляет желать лучшего, а то, что поддерживает MS в качестве решения — стоит дорого и не гарнтировано работает, по заявлению тех же MS.
FailOver миграция машин гарантирована тольок с полным выключением, без выключения 50-80% машин выпадают в BSOD — печальная статистика.
API для резервирования VM, у MS все еще не готово, есть инструменты, но реализованы они не полностью и не покрывают всего списка потребностей при резервировании, и уж тем-более мало пригодны для гранулярного восстановления. Только избранные продукты и только в определенных конфигурациях, как то Exchange, AD, *SQL.
Я же не утверждаю, что MS не пригодно, я лишь хочу скахать, что оно пригодно, но довольно ограниченно. Если это перекрывает потребности — то не вижу никаких преград.
А по стоимости — тут, как-бы, ничего не буду комментировать — есть интернет, сайты, прайсы, руки и голова. Я выразил свое ИМХО, так как плотно занимаюсь железом HP, по долгу службы, и озвученные цены на конфигурации меня, мягко говоря, удивили.
FailOver миграция машин гарантирована тольок с полным выключением, без выключения 50-80% машин выпадают в BSOD — печальная статистика.
А на VMware при отказе хоста они продолжают работать?
Только избранные продукты и только в определенных конфигурациях, как то Exchange, AD, *SQL.
Так у всех, Veeam и TSM VE тоже поддерживают гранулярное восстановление лишь для приложений от MS.
А на VMware при отказе хоста они продолжают работать?
Да. Машина моментально перезапускается на другой ноде без перезагрузки всей системы. Даже окна открытые остаются и буфер обмена. При запущенном пинге — недоступность машины составляет 2-4 пакета (но тут вопрос чисто сетевой).
Вимом R2 восстанавливал много чего не MS-овского на VMware (гранулярно). На Хайпере же то-же самое даже не предлагает.
1. Вы путаете живую миграцию и фейловер, у обоих вендоров они работают примерно одинаково. Хотя не уверен, что у VMware RDMA.
2. Veeam для Hyper-V не использовал, но в справке не сказано о каких-либо ограничениях.
2. Veeam для Hyper-V не использовал, но в справке не сказано о каких-либо ограничениях.
* Не уверен, что VMware умеет задействовать RDMA для ускорения живой миграции.
С другой стороны — в Hyper-V нет компресси и дедупликации памяти, которая может быть полезна в VDI и тестовых инфраструктурах.
С другой стороны — в Hyper-V нет компресси и дедупликации памяти, которая может быть полезна в VDI и тестовых инфраструктурах.
Вроде не путаю. Рестарт системы будет только в том, случае, если есть хардварное различие между нодами и не настроен EVC.
По крайней мере, при сбое одной из нод, виртуальные машины переезжают без ребута. Исключение сотавляют машины на которых не запущены VmwareTools.
Лицензия Essential. Проверено на ESX 5.1/5.5
По крайней мере, при сбое одной из нод, виртуальные машины переезжают без ребута. Исключение сотавляют машины на которых не запущены VmwareTools.
Лицензия Essential. Проверено на ESX 5.1/5.5
Фейловер означает восстановление ВМ в случае мгновенного отказа хоста, например, при отказе по питанию или PSOD/BSOD.
В этом случае ВМ стартуют на другом хосте как после жесткого выключения и VMTools тут не помогут, а EVC вообще ни при чем, так как процессор опередляется при включении.
В этом случае ВМ стартуют на другом хосте как после жесткого выключения и VMTools тут не помогут, а EVC вообще ни при чем, так как процессор опередляется при включении.
Да, это написано в документации, однако я был приятно удивлен таким поведением, как я описал. Буквально в среду у нас упала одна нода. Все запущенные приложения остались рабочими после переезда на другую ноду.
Даже затрудняюсь представить как такое возможно. Для этого надо иметь полностью консистентную реплику памяти на другой ноде. Есть режим FT у VMWare, но он резервирует память на другой ноде (сюрприз) и имеет ограничение в 1 vCPU у виртуалки.
На Essential нет даже HA. Наверно речь о Essential Plus. Переключение без перезагрузки ВМ возможно, но у VMware это одно ядро (пока). Есть ещё такое решение количество ядер не ограничено www.youtube.com/watch?v=5wAUq5lVNBI
Фактически два сервера синхронизированы.
Фактически два сервера синхронизированы.
А еще у VMWare есть тенденция впадать в панику при любых проблемах с СХД. У меня как-то козлил коммутатор, через который ходил iSCSI. Так вот кластер на Hyper-V (правда 2012 R2 уже) деградировал по производительности, но работал, а VMWare впал в такой ступор, что с него даже файлы образов виртуалок достать не удалось. Часть машин потухла и не поднималась, мелкие линксы более-менее работали, vSphere вообще отказался что-либо делать с iSCSI хранилищем. А Hyper-V тем временем спокойно пережил рестарт коммутатора.
Была еще какая-то (не помню точно какая, не сам разбирался) проблема с Jumbo Frame у VMWare. Так и не смогли завести нормально iSCSI MPIO с включенными Jambo Frame. А выключить его (да-да именно это и посоветовали) тоже целый квест. Я уж молчу про ограничение в 32ГБ памяти, которое было до последнего. В то время как у Hyper-V можно купить Server DataCenter и за ОС внутри виртуалок не платить.
Проброс USB чем дальше, тем менее нужен.
Виртуалки прекрасно резервируются DPM-ом или сторонними средствами. Вообще VSS прекрасная вещь, ее бы еще кто-нибудь сторонний поддерживал.
Реальный косяк Hyper-V в том, что он до сих пор не умеет грузить виртуалки (Gen2 не счет, туда мало что поставишь) со SCSI контроллера, как следствие не работает расширение диска на лету, например.
В общем говорить, что Hyper-V прямо уж так хуже VMWare — не верно. У каждой системы свои косяки и свои плюсы.
Была еще какая-то (не помню точно какая, не сам разбирался) проблема с Jumbo Frame у VMWare. Так и не смогли завести нормально iSCSI MPIO с включенными Jambo Frame. А выключить его (да-да именно это и посоветовали) тоже целый квест. Я уж молчу про ограничение в 32ГБ памяти, которое было до последнего. В то время как у Hyper-V можно купить Server DataCenter и за ОС внутри виртуалок не платить.
Проброс USB чем дальше, тем менее нужен.
Виртуалки прекрасно резервируются DPM-ом или сторонними средствами. Вообще VSS прекрасная вещь, ее бы еще кто-нибудь сторонний поддерживал.
Реальный косяк Hyper-V в том, что он до сих пор не умеет грузить виртуалки (Gen2 не счет, туда мало что поставишь) со SCSI контроллера, как следствие не работает расширение диска на лету, например.
В общем говорить, что Hyper-V прямо уж так хуже VMWare — не верно. У каждой системы свои косяки и свои плюсы.
>Экономии пора — закончилась. Особенно в вопросе виртуализации >инфраструктур. Если кто-то застрял во времени — его право.
>Единая СХД имеет смысл в составе кластера с поддержкой LM или HA как >минимум. При Standalone-ахитектуре данный подход имеет мало смысла.
Очень сильно заблуждаетесь. Всё зависит от решаемых задач, а конкретно, от стоимости простоя. В нашем случае речь идёт о middle-size businness, если сервисы встанут на сутки, компания не несёт многомиллионых убытков, у нас нет интернет магазина, мы не дата-центр веб хостинга, не атомная станция и не банк. В нашем случае есть два варианта. Платный и бесплатный. Бесплатный — это когда хост ESXi умирает, а это в масштабах малых инсталяций бывает раз в несколько лет, я утром прихожу и перезапускаю машины на резервном хосте ESXi. Платный вариант — это 1700 баксов за сокет и примерно 4000 баксов за вицентр, который будет несколько лет фактически простаивать и может быть, когда-нибудь, в случае отказа, однажды за несколько лет автоматически перезапустит виртуалки на другом хосте ESXi. Что даёт бесплатная инсталляция? ОЧЕНЬ МНОГО — модульность, масштабируемость и огромную гибкость. СХД позволяет перераспределить диски между серверами, гипервизор нивилирует зависимость от железа, получаем легко наращиваемую и очень гибкую систему. Ну и резервирование, с ручным перезапуском, что приемлемо для очень многих задач.
>Единая СХД имеет смысл в составе кластера с поддержкой LM или HA как >минимум. При Standalone-ахитектуре данный подход имеет мало смысла.
Очень сильно заблуждаетесь. Всё зависит от решаемых задач, а конкретно, от стоимости простоя. В нашем случае речь идёт о middle-size businness, если сервисы встанут на сутки, компания не несёт многомиллионых убытков, у нас нет интернет магазина, мы не дата-центр веб хостинга, не атомная станция и не банк. В нашем случае есть два варианта. Платный и бесплатный. Бесплатный — это когда хост ESXi умирает, а это в масштабах малых инсталяций бывает раз в несколько лет, я утром прихожу и перезапускаю машины на резервном хосте ESXi. Платный вариант — это 1700 баксов за сокет и примерно 4000 баксов за вицентр, который будет несколько лет фактически простаивать и может быть, когда-нибудь, в случае отказа, однажды за несколько лет автоматически перезапустит виртуалки на другом хосте ESXi. Что даёт бесплатная инсталляция? ОЧЕНЬ МНОГО — модульность, масштабируемость и огромную гибкость. СХД позволяет перераспределить диски между серверами, гипервизор нивилирует зависимость от железа, получаем легко наращиваемую и очень гибкую систему. Ну и резервирование, с ручным перезапуском, что приемлемо для очень многих задач.
Да, вы по своему правы. Существует несколько подходов к оценке проектов.
То о чем говорите Вы — это называется «ресурсный подход», когда оцениваются затраты на необходимые ресурсы для решения вполне конкретных проектов. В первом приближении.
Плюс данного подхода, как и его цель — краткосрочные перспективы. «Быстрые проекты».
Минус — он не эффективен при расчете сложных многоцелевых проектов и абсолютно «нулевой» при долгосрочных и среднесрочных задачах.
Есть подход «целевой» — когда оценивается не затраты на ресурсы, а затраты на достижение определенных целей.
Он позволяет заранее определить пулы необходимых ресурсов и наиболее эффективно распределить затраты.
Я сторонник именно этого подхода.
Ничего личного, каждый жонглирует как он хочет. Я вашего бизнеса не знаю, возможно вам этого достаточно.
Автор озаглавил пост как «отказоустойчивый», но отказоустойчивость и высокодоступность не одно и тоже, особенно в рамках Вами описанного кейса.
Возможно я сгущаю краски, но я делюсь опытом. Если не интересно, можете дальше не читать.
Ведь не все упирается тольок в стоимость простоя, но и в стоимость той самой «гибкости». Завтра власть переменилась, изменились приоритеты, проекты, экономика и бизнес уже требует решения других задач с другим SLA (что, как показывает практика, случается немного чаще, чем хотелось-бы, особенно в больших компаниях), а инфраструктура не готова к подобному повороту. И вот тут встает вопрос, а что было-бы, если бы мы изначально продумали возможность изменения портфеля сервисов?
Вот здесь я не соглашусь, так как без консолидированного управления всем этим зоопарком ни о какой гибкости и масштабируемости не может быть и речи. Вы получаете не «легко наращиваемую», а «просто еще одну систему». В контексте виртуализации, наращиваемая система — это единая система, у которой меняется тот или оной параметр в процессе эксплуатации. В случае со стэндэлоун — мы просто увеличиваем количество систем, но не масштабируем и не наращиваем. Единственное, к чему тут можно применить этот термин, так это к количеству железных серверов.
Вообще, по большому счету — ESX, как и любой другой гипервизор — это не сервис как таковой (если мы не продаем ресурсы за деньги), это поддерживающий сервис, который уже позволяет легко масштабировать СЕРВИСЫ, но сам по себе он практически не масштабируем.
То о чем говорите Вы — это называется «ресурсный подход», когда оцениваются затраты на необходимые ресурсы для решения вполне конкретных проектов. В первом приближении.
Плюс данного подхода, как и его цель — краткосрочные перспективы. «Быстрые проекты».
Минус — он не эффективен при расчете сложных многоцелевых проектов и абсолютно «нулевой» при долгосрочных и среднесрочных задачах.
Есть подход «целевой» — когда оценивается не затраты на ресурсы, а затраты на достижение определенных целей.
Он позволяет заранее определить пулы необходимых ресурсов и наиболее эффективно распределить затраты.
Я сторонник именно этого подхода.
Ничего личного, каждый жонглирует как он хочет. Я вашего бизнеса не знаю, возможно вам этого достаточно.
Автор озаглавил пост как «отказоустойчивый», но отказоустойчивость и высокодоступность не одно и тоже, особенно в рамках Вами описанного кейса.
Возможно я сгущаю краски, но я делюсь опытом. Если не интересно, можете дальше не читать.
Ведь не все упирается тольок в стоимость простоя, но и в стоимость той самой «гибкости». Завтра власть переменилась, изменились приоритеты, проекты, экономика и бизнес уже требует решения других задач с другим SLA (что, как показывает практика, случается немного чаще, чем хотелось-бы, особенно в больших компаниях), а инфраструктура не готова к подобному повороту. И вот тут встает вопрос, а что было-бы, если бы мы изначально продумали возможность изменения портфеля сервисов?
Что даёт бесплатная инсталляция? ОЧЕНЬ МНОГО — модульность, масштабируемость и огромную гибкость. СХД позволяет перераспределить диски между серверами, гипервизор нивилирует зависимость от железа, получаем легко наращиваемую и очень гибкую систему. Ну и резервирование, с ручным перезапуском, что приемлемо для очень многих задач.
Вот здесь я не соглашусь, так как без консолидированного управления всем этим зоопарком ни о какой гибкости и масштабируемости не может быть и речи. Вы получаете не «легко наращиваемую», а «просто еще одну систему». В контексте виртуализации, наращиваемая система — это единая система, у которой меняется тот или оной параметр в процессе эксплуатации. В случае со стэндэлоун — мы просто увеличиваем количество систем, но не масштабируем и не наращиваем. Единственное, к чему тут можно применить этот термин, так это к количеству железных серверов.
Вообще, по большому счету — ESX, как и любой другой гипервизор — это не сервис как таковой (если мы не продаем ресурсы за деньги), это поддерживающий сервис, который уже позволяет легко масштабировать СЕРВИСЫ, но сам по себе он практически не масштабируем.
DL360 Gen8 на итаниумах? Такого не бывает.
Эта система не для сервера терминалов, внутри виртуальные машины сервера приложений, сервера баз данных, сервера антивируса, прокси сервера, сервера wds, exchange. Пользователи работают на своих hp 8300 elite с i5 процессором, мы никого не обижали…
Неработоспособно — это зависит от задач. Те же тонкие клиенты, когда вся работа в терминал вполне неплохо себя чувствуют во многих отраслях.
Каждый сервер обошелся в почти миллион рублей
Недавно покупали
IBM System X 3550 M4:
2 x Xeon E5-2670v2 (10 Core)
192 Gb PC-14900 ECC DDR3
2 HBA Qlogic
Additional PowerSupply
8 SSD 256GB
638 т. руб.
Россия… такая Роиссия.
Очень странные цены. Это железо или вместе с софтом? Недавно собирали подобное решение на деловском оборудовании, две ноды + СХД с двумя полками, сервер под резервные копии + ленточная библиотека, общий бюджет всего решения 1,3 ляма, контора так же на 200 человек. Общая производительность дисковой примерно 2000 iops, сервера при этом практически на загружены, процессора процентов на 20 максимум. Сейчас в память упёрлись, но с выходом ESXi 5.5 ограничений по памяти больше нет.
Ну и наша компания не платила за это ни копейки… Это то, что мы смогли обосновать и отстоять в определенных бюджетных рамках ген. подрядчику строительства…
Профиль: Адлер. Адлер --> Сочи.
На эти «ни копейки» получается вам всей страной скинулись? ;-)
А 4 диска в запасе тоже не безосновательно, кто работал в газпроме или пригазпромовских организациях знает, что бюджет на будущий год заканчивают планировать в апреле, более того процедура закупки может длиться около полугода, посему страхуемся, любим спать спокойно)
На MSA не стоит делать такие маленькие RAID-группы (4 диска RAID-10), это даст всего 400 IOPs на чтение и 200 на запись. Лучше было бы сделать 2 группы по 12 дисков RAID-50 на двух контроллерах для балансировки (MSA — ALUA-массив, ввод-вывод на VRAID идет через один контроллер-владелец), либо из 22 дисков с 2 в Hot Spare. Так бы получили до 2500 IOPs на чтение и чуть больше 400 при 100% записи.
В вашей конфигурации dedicated spares для VRAID тоже так себе, можно же использовать Global Spares.
В вашей конфигурации dedicated spares для VRAID тоже так себе, можно же использовать Global Spares.
Ну и да, переходите на светлую сторону (VMware), там все гораздо интереснее :)
UFO just landed and posted this here
Именно. Бизнесу часто вообще без разницы, как выполнена задача, но приветствуется экономия финансовых ресурсов.
Но бесплатная редакция hyper-v server даже без управляющего system center (хотя 800usd и не очень большая сумма, в общем-то для тех, у кого много аппаратных гипервизоров), если мне не изменяет память, очень выигрывает у ESXi, бесплатная лицензия у которого, мягко говоря, сильно урезана по функционалу, хотя за подробностями уже надо лезть в документацию, на 5.1 и 5.5 много интересных изменений.
К сожалению, что у тех, что у других что у третьих (Xen, да), до сих пор хватает болячек, ньюансов, проблем и глюков, но тенденции в тяге к лучшему чем дальше, тем больше радуют.
Но бесплатная редакция hyper-v server даже без управляющего system center (хотя 800usd и не очень большая сумма, в общем-то для тех, у кого много аппаратных гипервизоров), если мне не изменяет память, очень выигрывает у ESXi, бесплатная лицензия у которого, мягко говоря, сильно урезана по функционалу, хотя за подробностями уже надо лезть в документацию, на 5.1 и 5.5 много интересных изменений.
К сожалению, что у тех, что у других что у третьих (Xen, да), до сих пор хватает болячек, ньюансов, проблем и глюков, но тенденции в тяге к лучшему чем дальше, тем больше радуют.
«Обеспечить спокойный сон отделу ИТ» — это совершенная ложь. К этой всей тряхомудии допродали ещё техподдержки и одного-двух админов, которые будут скакать вокруг этой винды с бубнами, что бы оно не глючило.
А потом, когда посыпятся через полгода так любимые горе-одминчиками аппаратные SAS-контроллеры без возможности восстановить данные, надеюсь, что автора схемы найдут и спросят.
А потом, когда посыпятся через полгода так любимые горе-одминчиками аппаратные SAS-контроллеры без возможности восстановить данные, надеюсь, что автора схемы найдут и спросят.
А что в данной стандартной схеме разворачивания кластерных решений Вам кажется странным и ненадёжным? По всем пунктам согласен с автором, на выходе — модульное, легко расширяемое решение. Может быть Вы через чур консервативны?
Мы админим эту сеть с момента начала строительства, с времен временных сеток, вайфай мостов между зданиями, и серверов на обычных компах, где все постоянно ломалось и не работало… Сейчас у нас по оптике кольцо между всеми зданиями, стабильно работающие сервера, дисковое хранилище, резервирование каналов связи, два ввода питания + 90 часов запаса на аккумуляторных стилажах.
Сейчас не происходит ничего, что может потребовать моего немедленного участия, как это было раньше, все терпит до утра)))
Кстати я не думаю что велик шанс отказа сразу двух контроллеров у дисковой полки.
Сейчас не происходит ничего, что может потребовать моего немедленного участия, как это было раньше, все терпит до утра)))
Кстати я не думаю что велик шанс отказа сразу двух контроллеров у дисковой полки.
А что за кольцо по оптике? FDDI? Расскажите плз более подробно.
По поводу отказа СХД — не все элементы в СХД дублируются, например, пассивный бэкплейн и SAS-экспандеры, в дешёвых СХД могут быть проблемы с софтом, который реализует failover и много много прочих проблем. Т.е. у Вас обязательно должен быть предусмотрен какой-то резервный план на случай отказа СХД. Я например специально брал сервера с большими корзинами, в крайнем случае можно будет винты просто по серверам раскидать.
По поводу отказа СХД — не все элементы в СХД дублируются, например, пассивный бэкплейн и SAS-экспандеры, в дешёвых СХД могут быть проблемы с софтом, который реализует failover и много много прочих проблем. Т.е. у Вас обязательно должен быть предусмотрен какой-то резервный план на случай отказа СХД. Я например специально брал сервера с большими корзинами, в крайнем случае можно будет винты просто по серверам раскидать.
Про оптику рассказывать нечего, там stp… Намного интереснее организация резервирования каналов передачи. Там и stand by group и ip sla, track и event track. Могу отдельную статью сделать, если это интересно кому-нибудь.
Схд у нас не самый дешевый, но вы заставили задуматься, может быть закажем еще одну корзину и в будущем году попробуем что-нибудь сделать с доступностью файлового хранилища.
Я понимаю, что у нас не лучшая инфраструктура, но я рассчитывал на такие комментарии, чтобы понять к чему нам стремиться, за что я всех комментаторов благодарю.
Схд у нас не самый дешевый, но вы заставили задуматься, может быть закажем еще одну корзину и в будущем году попробуем что-нибудь сделать с доступностью файлового хранилища.
Я понимаю, что у нас не лучшая инфраструктура, но я рассчитывал на такие комментарии, чтобы понять к чему нам стремиться, за что я всех комментаторов благодарю.
Ну, SAS-СХД навроде Вашей считается lo-end устройством, т.е. СХД начального уровня. Она много чего не умеет, например, не поддерживает репликацию на другую СХД.
Ну и кроме этого, у меня ещё есть придирка по терминологии.
Если у Вас на оптике STP, значит это обычный Ethernet и говорить «петля по оптике» некорректно. Петля в терминологии Ethernet означает нежелательное состояние сети, во время которого сеть не работает. Кроме того Вы упоминаете про STP, который собственно и борится с подобными петлями, а значит у Вас петель тем более нет. «Петля по оптике» может быть корректным в отношении технологий Token Ring/FDDI, где сеть строится по принципу Кольцо, по которому гуляет маркер и т.п. Оптика Ethernet на L2 уровне не отличается от витой пары, это обычное соединение например двух коммутаторов. Можно взять и поменять трансиверы и вместо оптики подключить витую пару. Топология не изменилась, изменилась только среда передачи данных, откуда тогда берётся петля? Вы же не говорите про витую пару «петля по витой паре»?
Ну и кроме этого, у меня ещё есть придирка по терминологии.
Если у Вас на оптике STP, значит это обычный Ethernet и говорить «петля по оптике» некорректно. Петля в терминологии Ethernet означает нежелательное состояние сети, во время которого сеть не работает. Кроме того Вы упоминаете про STP, который собственно и борится с подобными петлями, а значит у Вас петель тем более нет. «Петля по оптике» может быть корректным в отношении технологий Token Ring/FDDI, где сеть строится по принципу Кольцо, по которому гуляет маркер и т.п. Оптика Ethernet на L2 уровне не отличается от витой пары, это обычное соединение например двух коммутаторов. Можно взять и поменять трансиверы и вместо оптики подключить витую пару. Топология не изменилась, изменилась только среда передачи данных, откуда тогда берётся петля? Вы же не говорите про витую пару «петля по витой паре»?
UFO just landed and posted this here
Зря вы так. Hyper-v — вполне себе зрелый продукт. Пляски на стадии развёртывания. На стадии эксплуатации — не заметил. Но, извиняюсь, я и вокруг других систем плясал. Определяется во многом опытом.
И бэкапы. Бэкапы наше всё. Или все яйца в одной корзине? Где продакшн, там и бэкапы?
И бэкапы. Бэкапы наше всё. Или все яйца в одной корзине? Где продакшн, там и бэкапы?
HP P200 Вроде давно сняли с производства, да и есть много намного вкусных за эти же деньги.
Что за LH4000 скажете?
За ту же сумму и 2 ноды, емкость, софт нормальный, и не глючит как P2000, хотя тоже устарела уже.
За ту же сумму и 2 ноды, емкость, софт нормальный, и не глючит как P2000, хотя тоже устарела уже.
Конфиг серваков мне совершенно не понятен, почему так мало памяти? Учитывая что это MS доступно к использованию всего по 32 ГБ на узел, иначе фаловер не сработает. Надо было брать 4 DL360/380. И дешевле вышло бы.
Sign up to leave a comment.
Подготовка инфраструктуры и развертывание отказоустойчивого кластера на Windows Server 2012