Comments 21
На старой работе использовали MSA2000G1 (2012 c LFF и FC) под хранение картинок фотоальбомов на сайте и загруженного пользователями видео. Отлично справлялось.
Начальное хранилище, обросшее лицензиями. Статья — реклама в условиях падения спроса из-за курса валют и политики hp.
Эх… мне бы её домой на пару-тройку месяцев...:(
Зачем дома шумный, дорогой и тяжёлый ящик, к тому же не с тем функционалом? Дома обычно нужны файловый доступ с умеренной производительностью, тишина, всякие сервисы типа DLNA.
Ну как сказать — каждому своё. У меня под хранение сейчас Synology DS414j используется, но рядом с ним стоят и работают HP DL360 G6 и IBM BladeCenter S. Да и разные большие железки периодически ко мне приезжают для обзоров. Вот недавно G9 ML350 у меня тут гудел — очень даже классно :) В большей степени СХДшка мне нудна для учёбы, я с ними практически не работал, сейчас осваиваю теорию SAN/СХД и без железки для практики крайне тяжело конечно и скучно. Вот по этому да — хотел бы. Оплата электричества за 2-3 месяца её работы в любом случае на мноооого дешевле чем даже самые дешёвые недельные курсы от HP по СХД за 100k рублей :(
В MSA «пару-тройку месяцев» учить нечего, и, более того, «выучив» MSA, вы научитесь работать только с ней, что особо ничем вам не поможет, когда/если вам в руки попадет железка более высокого уровня (или хотя бы даже entry level от других вендоров). Не говоря уже о том, что наличие у вас в руках железки не особо поможет в знании внутренних алгоритмов её работы. А если вам нужна «теория SAN/СХД» в плане того, чем СХД вообще отличается от локального диска, сделайте из любого вашего сервера iSCSI target и экспериментируйте.
недавно такой мегат… х имел с 2040 — оказалось два контроллера биты, точнее флешка CF на обоих.
Каким образом консолидация является методом повышения надёжности? Раньше у меня данные лежали на 30 разных серверах в разных стойках и разных ДЦ, и спокойно переживали смерть чего угодно — и ДЦ, и питания в стойке, и серверов, и дисков.
Я сложил все данные в «консолидированную» коробочку, а она накрылась. Например, на неё пролили ведро мокрой воды. Или уронили работающую болгарку. Или погрузчик вилой проткнул весь дисковый массив. Или просто банальный пожар.
Скажите, ваша «консолидированная система, повышающая надёжность», она сколько погрузчиков выдержит? Моя предыдущая, с 30 разными серверами — штук 15.
Я сложил все данные в «консолидированную» коробочку, а она накрылась. Например, на неё пролили ведро мокрой воды. Или уронили работающую болгарку. Или погрузчик вилой проткнул весь дисковый массив. Или просто банальный пожар.
Скажите, ваша «консолидированная система, повышающая надёжность», она сколько погрузчиков выдержит? Моя предыдущая, с 30 разными серверами — штук 15.
Зря удалили из комментария ведро и погрузчик, это было весело =)))
У меня на обслуживании больше 10 MSA P2000 G3 SAS, суммарно установлено больше 120 дисков
Про надежность (за 4-5 лет):
1 — заменил 3 хдд.
2 — недавно из за ошибка есс в оперативной памяти контроллера, заменил контроллер
3 — один раз при обновлении неудачно порошился один контроллер, но СХД осталась в рабочем состоянии
HP MSA очень надежные системы, хотя при вводе в эксплуатации нужно быть внимательным
Любая техника ломается, вопрос в том как быстро пройдет восстановление
Покупали кер пак только на центральную СХД, как показала практика это можно было не делать, зпч на СХД с стандартной гарантией привозили на NBD.
Затем на все СХД приобрели послегарантийные кер паки…
Про пожар:
1 — а 30 серверов как-то лучше переживут пожар?
2 — Недавно пришлось включить репликацию между центральным сайтом и регионом,
Я был удивлен с каналом 15 мбит, синхронизируется терминальный сервер, 1с сервер и производственный сервер (суммарный размер 250 гб) в худшем случаи после переиндексации бд 1с длится 2 часа, в рабочее время изменения передаются за пару минут.
Реплицирую средствами VMware, в начале даже думал про замену контроллеров, чтобы средствами MSA делать репликацию.
Про MSA:
1 — Пока не вышло ж8 поколение серверов где изменили салазки для дисков, была мега возможность переставить диски из сервера в СХД, мы так и сделали, теперь это не прокатит пока не выйдет новое поколение MSA.
2 — Поставщики периодически пугали что MSA снимут с производства, но прошло время и появились 2040 и 1040, но я не считаю это слабым апдейтом
3 — для SMB использование SAS дешевле, HP не предлагает SAS коммутаторы для раковых серверов, только для блейдов, может что-то уже изменилось, в этой статье про возможность подключения к СХД по SAS вообще забыли.
У меня на обслуживании больше 10 MSA P2000 G3 SAS, суммарно установлено больше 120 дисков
Про надежность (за 4-5 лет):
1 — заменил 3 хдд.
2 — недавно из за ошибка есс в оперативной памяти контроллера, заменил контроллер
3 — один раз при обновлении неудачно порошился один контроллер, но СХД осталась в рабочем состоянии
HP MSA очень надежные системы, хотя при вводе в эксплуатации нужно быть внимательным
Любая техника ломается, вопрос в том как быстро пройдет восстановление
Покупали кер пак только на центральную СХД, как показала практика это можно было не делать, зпч на СХД с стандартной гарантией привозили на NBD.
Затем на все СХД приобрели послегарантийные кер паки…
Про пожар:
1 — а 30 серверов как-то лучше переживут пожар?
2 — Недавно пришлось включить репликацию между центральным сайтом и регионом,
Я был удивлен с каналом 15 мбит, синхронизируется терминальный сервер, 1с сервер и производственный сервер (суммарный размер 250 гб) в худшем случаи после переиндексации бд 1с длится 2 часа, в рабочее время изменения передаются за пару минут.
Реплицирую средствами VMware, в начале даже думал про замену контроллеров, чтобы средствами MSA делать репликацию.
Про MSA:
1 — Пока не вышло ж8 поколение серверов где изменили салазки для дисков, была мега возможность переставить диски из сервера в СХД, мы так и сделали, теперь это не прокатит пока не выйдет новое поколение MSA.
2 — Поставщики периодически пугали что MSA снимут с производства, но прошло время и появились 2040 и 1040, но я не считаю это слабым апдейтом
3 — для SMB использование SAS дешевле, HP не предлагает SAS коммутаторы для раковых серверов, только для блейдов, может что-то уже изменилось, в этой статье про возможность подключения к СХД по SAS вообще забыли.
для SMB использование SAS дешевле, HP не предлагает SAS коммутаторы для раковых серверов
Мы когда-то усиленно продвигали свитчи LSI 6160, но они как-то не прижились, да и сам LSI забил на развитие: HCL не обновляется (MSA 2040 там нет, не помню, тестировал ли у нас), планы по выпуску SAS3 свитча отодвинулись.
Вначале всё получается относительно недорого и быстро, а потом приходит боль от ограничений: 1) дистанция 2) по SAS нет репликации
Есть ещё, конечно, такой костыль, как Chelsio USR-1100. Но зачем?
Если практика в проектах показывает что SAS не подходит, тот тут я спорить не буду
1 — На дистанциях в 2-3 шкафа, проблем с длиной для SAS не должно быть.
При росте количества серверов за пределы одного шкафа возникает вопрос актуальности блейдов, и цена в проекте будет очень заманчивая.
2 — Как мне известно в MSA синхронная репликация отсутствует, а асинхронную отлично могут делать сервера средствами гипервизора.
Chelsio USR-1100, какой интересный мфу =)
1 — На дистанциях в 2-3 шкафа, проблем с длиной для SAS не должно быть.
При росте количества серверов за пределы одного шкафа возникает вопрос актуальности блейдов, и цена в проекте будет очень заманчивая.
2 — Как мне известно в MSA синхронная репликация отсутствует, а асинхронную отлично могут делать сервера средствами гипервизора.
Chelsio USR-1100, какой интересный мфу =)
Каким образом консолидация является методом повышения надёжности?
Ну очевидно же, что смотря с чем сравнивать. Речь о массивах начального уровня, на которые обычно переходят с «системы» в виде N не пойми каких серверов (зачастую собранных из десктопных комплектующих), каждый из которых содержит свой набор данных, который нигде не дублируется.
что-то я сомневаюсь, что есть разница, если ведро воды выльют сверху на вашу стойку с 30-ю серверами. ))
начали за консолидацию, закончили за катастрофоустойчивость (DR). да, и с таким же успехом вы можете поставить еще одну эмэсейку в другой цод. (hp remote snap)
и мне кажется, что в контексте «Консолидация данных – один из способов повышения производительности, надежности и управляемости информационной системы предприятия» говорится о том, что данные не поместили в «нищебродсервер», а расположили на массиве, где критические компоненты дублируются, тем самым повышая уровень надежности за малое кол-во размещения юнит/сервер.
начали за консолидацию, закончили за катастрофоустойчивость (DR). да, и с таким же успехом вы можете поставить еще одну эмэсейку в другой цод. (hp remote snap)
и мне кажется, что в контексте «Консолидация данных – один из способов повышения производительности, надежности и управляемости информационной системы предприятия» говорится о том, что данные не поместили в «нищебродсервер», а расположили на массиве, где критические компоненты дублируются, тем самым повышая уровень надежности за малое кол-во размещения юнит/сервер.
Мне вчера на тест как раз прибыл OEM-родственник HP MSA2040 — DotHill 4004, с 20x 147ГБ 15k HDD и 4x400GB SSD (HGST SSD400M). Посмотрю, как работает tiering и другие интересные штуки.
Неинтересно же без цен, дайте хоть ориентировочные цифры :)
А есть возможность два устройства MSA2040 объединить в RAID10 или его подобие? В админ интерфейсе никаких намеков на эту возможность
Коллеги, подскажите, пожалуйста где можно найти подробную информацию по HP P2000 G3 FC:
1. можно ли организовать резервное копирование снятием snapshot по расписанию?
2. насколько подходит снятие snapshot при работе с базами данных?
3. будет ли корректно создан snappool в случае если создан 1 vdisk (и на нем уже есть данные) из всех доступных физических дисков?
4. в случае если создан 1 vdisk из всех доступных физических дисков, каким образом будет влиять на этот vdisk выход из строя одного из двух контроллеров СХД? Произойдет ли деградация RAID массива или второй контроллер возьмет на себя управление?
1. можно ли организовать резервное копирование снятием snapshot по расписанию?
2. насколько подходит снятие snapshot при работе с базами данных?
3. будет ли корректно создан snappool в случае если создан 1 vdisk (и на нем уже есть данные) из всех доступных физических дисков?
4. в случае если создан 1 vdisk из всех доступных физических дисков, каким образом будет влиять на этот vdisk выход из строя одного из двух контроллеров СХД? Произойдет ли деградация RAID массива или второй контроллер возьмет на себя управление?
1 и 2. Относится не только к MSA, а к снапшотам вообще. Снапшот сам по себе не является полноценной резервной копией, т.к. зависит от исходного тома, сняли снапшот — и бэкапим его. Это лишь способ обеспечить бэкап работающего приложения. Но появляется вторая проблема — целостность данных при снятии снапшота.
Если мы просто получаем состояние тома, с которым работало некое приложение в определённый момент времени, то с большой вероятностью получим кашу — какие-то транзакции не завершились и т.п., как если бы мы просто нажали ресет перед бэкапом. Для решения этой проблемы придумали VSS (приложение узнает, что его хотят «заснапшотить», завершает все невыполненные операции и сообщает о готовности), а для автоматизации — куча разного софта, от HP Recovery Manager до всяких Symantec BE и прочих продуктов.
В VMware для этого свои механизмы, долго писать.
3. Если на vdisk есть место под snappool, то почему бы нет.
4, Vdisk'ом в определённый момент времени владеет только один контроллер. При падении этого контроллера, второй подхватит его vdisk'и (и все тома на них, конечно). При наличии правильно настроенного MPIO от хостов ничего не отвалится.
Если мы просто получаем состояние тома, с которым работало некое приложение в определённый момент времени, то с большой вероятностью получим кашу — какие-то транзакции не завершились и т.п., как если бы мы просто нажали ресет перед бэкапом. Для решения этой проблемы придумали VSS (приложение узнает, что его хотят «заснапшотить», завершает все невыполненные операции и сообщает о готовности), а для автоматизации — куча разного софта, от HP Recovery Manager до всяких Symantec BE и прочих продуктов.
В VMware для этого свои механизмы, долго писать.
3. Если на vdisk есть место под snappool, то почему бы нет.
4, Vdisk'ом в определённый момент времени владеет только один контроллер. При падении этого контроллера, второй подхватит его vdisk'и (и все тома на них, конечно). При наличии правильно настроенного MPIO от хостов ничего не отвалится.
Sign up to leave a comment.
Дисковые массивы HP MSA как основа для консолидации данных