Comments 21
Все замечательно. Но есть несколько вопросов.
1) Зачем в данной схеме RP, если на обоих площадках есть VPLEX?
2) Канал между площадками не позволяет организовать синхронную репликацию? И собрать VPLEX в Metro конфигурацию?
3) Если синхронная репликация между площадками невозможна, то для каких целей куплен VPLEX на обе площадки?
1) Зачем в данной схеме RP, если на обоих площадках есть VPLEX?
2) Канал между площадками не позволяет организовать синхронную репликацию? И собрать VPLEX в Metro конфигурацию?
3) Если синхронная репликация между площадками невозможна, то для каких целей куплен VPLEX на обе площадки?
Синхронная репликация в данном случае была не нужна. Были хосты к которым было подключено LUNов на 28ТБ c часто изменяемыми данными, только один такой хост положил бы канал. В целом схема была такая — кастомер присылает список хостов и даты их физической миграции, мы заводим пары в RP и реплицируем данные, в дату перевозки репликацию останавливаем. Синхронная репликация даже пары таких хостов забила бы канал, в случае же с асинхронной мы могли балансировать нагрузку.
А насчет использования RP, в случае c двумя VPLEX для миграции пришлось бы строить geo cluster, данный вариант был предложен, но кастомер остановился на варианте с RP.
А насчет использования RP, в случае c двумя VPLEX для миграции пришлось бы строить geo cluster, данный вариант был предложен, но кастомер остановился на варианте с RP.
EMC уже отказалось от Geo конфигурации для VPLEX см. тут
Вместо него рекомендуют пользовать MetroPoint на базе интеграции все с тем же RecoverPoint.
По прежнему не совсем понятно для чего используется в приведенной схеме VPLEX на второй площадке (там где стоят VNX)?
С первой площадкой все более или менее ясно. На площадке сплиттер для RP живет на VPLEX-е, а к VPLEX-у подключены массивы «сторонних» вендоров. На второй площадке есть EMC VNX и сплиттер RP можно было поставить прямо на него. Почему был выбран другой вариант?
Вместо него рекомендуют пользовать MetroPoint на базе интеграции все с тем же RecoverPoint.
По прежнему не совсем понятно для чего используется в приведенной схеме VPLEX на второй площадке (там где стоят VNX)?
С первой площадкой все более или менее ясно. На площадке сплиттер для RP живет на VPLEX-е, а к VPLEX-у подключены массивы «сторонних» вендоров. На второй площадке есть EMC VNX и сплиттер RP можно было поставить прямо на него. Почему был выбран другой вариант?
Имеено по той же причине что и в первом DC — в планах использование СХД и других вендоров (уже используется IBM XIV)
Ну и в порядке бреда. Вспоминая старую байку про то, что самый быстрый способ передачи данных это фура груженная под завязку дисками CD-ROM и движущаяся по дороге со скоростью 100км\ч…
А не рассматривался вариант поставить временно СХД (или несколько) из второго ЦОДа в первый. И провести миграцию всех нужных сервисов средствами самого VPLEX, что было бы в разы быстрее, чем асинхронная репликация терабайтов данных? А затем единоразово перевезти эту СХД во второй ЦОД вместе с исходными хостами (а возможно и единственным кластером VPLEX Local)?
А не рассматривался вариант поставить временно СХД (или несколько) из второго ЦОДа в первый. И провести миграцию всех нужных сервисов средствами самого VPLEX, что было бы в разы быстрее, чем асинхронная репликация терабайтов данных? А затем единоразово перевезти эту СХД во второй ЦОД вместе с исходными хостами (а возможно и единственным кластером VPLEX Local)?
Промазал с ответом, перенес комментарий выше.
Как пользователь VPLEX (2 года мучаюсь), сочувствую людям, которым впарили этот хлам, потому что:
1. До сих пор у VPLEX нет интеграции с VNX и PowerPath
2. При большом количестве объектов управление тупит очень сильно (решение не предназначено для больших окружений, хотя парни из lufthansa как-то живут, хотел бы посмотреть как)
3. При проблемах с производительностью на одном из подлежащих массивах страдают все клиенты со всех подлежащих массивов
4. Отвратительный мониторинг (в официальных курсах написано следующее: используйте Excel для парсинга csv файлов, если хотите посмотреть исторические данные по производительности)
Мы тоже мигрировали большой объем данных (сотни ТБ), но использовали для этого LVM, а не VPLEX. Данный подход хорош тем, что в будущем, при помощи LVM, перепрыгнуть на новый СХД будет на много проще без использования костылей ввиде VPLEX и RP.
VPLEX это решение одной фичи — active-active на два ЦОДа, не более.
1. До сих пор у VPLEX нет интеграции с VNX и PowerPath
2. При большом количестве объектов управление тупит очень сильно (решение не предназначено для больших окружений, хотя парни из lufthansa как-то живут, хотел бы посмотреть как)
3. При проблемах с производительностью на одном из подлежащих массивах страдают все клиенты со всех подлежащих массивов
4. Отвратительный мониторинг (в официальных курсах написано следующее: используйте Excel для парсинга csv файлов, если хотите посмотреть исторические данные по производительности)
Мы тоже мигрировали большой объем данных (сотни ТБ), но использовали для этого LVM, а не VPLEX. Данный подход хорош тем, что в будущем, при помощи LVM, перепрыгнуть на новый СХД будет на много проще без использования костылей ввиде VPLEX и RP.
VPLEX это решение одной фичи — active-active на два ЦОДа, не более.
До сих пор у VPLEX нет интеграции с VNX и PowerPath
Можете более подробно развернуть, что имелось в виду под интеграцией?
Ну и не совсем понятно как может помочь LVM на дистанциях асинхронной репликации.
Под интеграцией понимается, что PowerPath должен показывать имена Storage Group и томов, как он это делает для VNX и VMAX, но не делает для VPLEX. Хотя в то же время утилита networker inquire показывает имена девайсов на VPLEX (обнаружили случайно).
В результате взаимодействие с администраторами серверов очень сильно усложнилось. Так же нет специальных политик и оптимизации под VPLEX/
LVM от Symantec решает эти задачи.
В результате взаимодействие с администраторами серверов очень сильно усложнилось. Так же нет специальных политик и оптимизации под VPLEX/
LVM от Symantec решает эти задачи.
По поводу имен томов нет возможности проверить. Но в Release Notes на PP 6.0 от сентября 2015 года в разделе «New features» написано дословно следующее:
Т.е. отдельный класс устройств «VPLEX» и оптимизация под них присутствует.
По прежнему не понимаю, как при помощи LVM может быть решена задача по асинхронной миграции данных, описанная в данной статье?
EMC VPLEX GeoSynchrony 5.3 support
Support for EMC VPLEX GeoSynchrony 5.3. VPLEX devices are managed by the vplex class.
Т.е. отдельный класс устройств «VPLEX» и оптимизация под них присутствует.
По прежнему не понимаю, как при помощи LVM может быть решена задача по асинхронной миграции данных, описанная в данной статье?
IMO это можно сделать так:
1) Убрать I/O;
2) Синхронизировать данные;
3) Добавить в VG новый PV;
4) Сделать pvmove;
5) Убрать старый PV из VG;
6) Вернуть I/O.
1) Убрать I/O;
2) Синхронизировать данные;
3) Добавить в VG новый PV;
4) Сделать pvmove;
5) Убрать старый PV из VG;
6) Вернуть I/O.
OR не убирая I/O с помощью LVM mirror, как написал AlexanderCam ниже.
В рамках описанной автором проблемы, ваше решение скорее всего не подойдет из-за слишком большого времени простоя при «узком» канале между ЦОД-ами. Т.е. нужно будет очень продолжительное время держать сервисы выключенными.
Решение уважаемого AlexanderCam тоже скорее всего не подойдет, т.к. синхронная репликация между ЦОД-ами, по словам автора k3lmiir, не возможна все из-за той же недостаточной ширины канала. А без этого «условно» синхронизация томов между ЦОД-ами не закончится ни когда (без остановки ввода\вывода с хостов). Плюс не уверен, что легко можно найти способ управления скоростью синхронизации при настройке LVM mirror. А забитый на 100% канал между ЦОД-ами, как я понял, то же заказчика никак не устраивал.
Решение уважаемого AlexanderCam тоже скорее всего не подойдет, т.к. синхронная репликация между ЦОД-ами, по словам автора k3lmiir, не возможна все из-за той же недостаточной ширины канала. А без этого «условно» синхронизация томов между ЦОД-ами не закончится ни когда (без остановки ввода\вывода с хостов). Плюс не уверен, что легко можно найти способ управления скоростью синхронизации при настройке LVM mirror. А забитый на 100% канал между ЦОД-ами, как я понял, то же заказчика никак не устраивал.
Как пользователь VPLEX (2 года мучаюсь), сочувствую людям, которым впарили этот хлам, потому что:
Мы только собираемся принять участие в этом празднике жизни. Для Active-Active есть всего два варианта, которые можно будет масштабировать еще, как минимум, 5 лет: EMC VPLEX и IBM SVC.
1. До сих пор у VPLEX нет интеграции с VNX и PowerPath
Какая интеграция имеется ввиду, SMI-S provider?
PowerPath/VE доступен для VPLEX Metro.
2. При большом количестве объектов управление тупит очень сильно (решение не предназначено для больших окружений, хотя парни из lufthansa как-то живут, хотел бы посмотреть как)
vipr/ucs director
3. При проблемах с производительностью на одном из подлежащих массивах страдают все клиенты со всех подлежащих массивов
LUN «растянут» на все подлежащие массивы? Если да, то тут все очевидно.
4. Отвратительный мониторинг (в официальных курсах написано следующее: используйте Excel для парсинга csv файлов, если хотите посмотреть исторические данные по производительности)
Согласен.
Данный подход хорош тем, что в будущем, при помощи LVM, перепрыгнуть на новый СХД будет на много проще без использования костылей ввиде VPLEX и RP.
Имеется ввиду pvmove?
Как пользователь VPLEX (2 года мучаюсь), сочувствую людям, которым впарили этот хлам
В нашем случае пришлось работать с тем что было, так как, к сожалению, дизайн писали не мы.
Мы только собираемся принять участие в этом празднике жизни. Для Active-Active есть всего два варианта, которые можно будет масштабировать еще, как минимум, 5 лет: EMC VPLEX и IBM SVC.
Уж лучше VPLEX, чем SVC :)
Вообще я рекомендую использовать VPLEX, только для тех приложений и сервисов, которым это реально надо, а не для всего и всех.
Какая интеграция имеется ввиду, SMI-S provider?
PowerPath/VE доступен для VPLEX Metro.
См. выше. ответил.
vipr
тоже упоси вас господь этим ужасом пользоваться. Я надеюсь в будущих версиях они с ним что-то сделают.
Имеется ввиду pvmove?
Просто делается зеркало для теукщих томов с новыми, а после того как синхронизация заканчивается — отрываем старые и все. Даунтайм был только для тех хостов, где LVM не стоял.
LUN «растянут» на все подлежащие массивы? Если да, то тут все очевидно.
В том-то и дело, что без растянутых LUN'ов. К сожалению очень сложно воспроизвести данный случай поэтому мы пока просто перейдем на 4-Egine конфигурацию для изоляции мощных потребителей на своих директорах.
vipr
1. Это стоимость ViPR. И звучит это примерно так — мы тут спецом сделали дерьмовое управление и интеграцию, чтобы стрясти с вас ещё кучу бабла. А поверьте мне, когда у вас будет пару десятков массивов и петабайт, то стоимость ViPR вас крайне удивит…
2. Не буду заниматься рекламой, но есть прекрасный вендор СХД, который предоставляет такой софт бесплатно.
Sign up to leave a comment.
Миграция данных с различных типов Storage с использованием технологий EMC VPLEX и EMC RecoverPoint