Защита датацентров и данных от катастроф на базе технологий Nutanix / Максим Шапошников (Nutanix)
•Download as PPTX, PDF•
0 likes•692 views
* RTO - Recovery Time Objective - максимальное время, за которое все ваши бизнес-задачи должны полностью быть восстановлены в работоспособное состояние после полной катастрофы ДЦ RPO - Recovery Point Objective - максимально приемлемый для ваших задач промежуток времени, за который вы готовы потерять данные. * Стратегии защиты и репликации ДЦ (1 to 1, 1 to many, many to many). далее см. - http://rootconf.ru/2015/abstracts/1817
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Защита датацентров и данных от катастроф на базе технологий Nutanix / Максим Шапошников (Nutanix)
Similar to Защита датацентров и данных от катастроф на базе технологий Nutanix / Максим Шапошников (Nutanix) (20)
More from Ontico
More from Ontico (20)
Защита датацентров и данных от катастроф на базе технологий Nutanix / Максим Шапошников (Nutanix)
- 1. Защита данных и датацентров от катастроф Максим Шапошников
- 2. Защита данных. Принципы (снизу вверх). • Отказ от RAID, в особенности аппаратных • Интеллектуальная распределенная ФС (локализация I/O) • Двойное или тройное резервирование блоков данных • Резервирование путей доступа к данным • Распределение данных с учетом аппаратных компонент • Интегрированные снапшоты «на лету» • Полный контроль над расписанием и политиками • Минимизация RPO / RTO • Асинхронная и синхронная репликация VM и датасторов • Резервирование в публичные облака
- 3. Защита данных. Нюансы. • Общий принцип – приложение знает лучше как резервировать / реплицировать свои данные Существует множество приложений, не умеющих это делать или делающих плохо • Синхронная репликация безопаснее всего, нулевая потеря данных На больших расстояниях (больше сотен километров) latency убьёт производительность • Асинхронная репликация данных – потеря данных в случае аварии Да, поэтому проектируйте или бизнес-логику исходя из возможной потери данных, или датацентры располагайте рядом
- 4. Защита данных. Лучшие практики. • Гибридная защита – уровень приложений там где возможно, асинхронная репликация как общее решение, метро-кластера для ключевых данных. • Выбор правильного решения, большинство аппаратных средств (СХД) репликация не проектировались с учетом «облачных» реалий (работают на уровне архаичных LUN, не VM-centric) • Репликация данных не заменяет бэкап. Как минимум – использовать регулярные снапошоты данных, в идеале – независимые бэкап решения
- 5. Nutanix Distributed File System базируется на доработанной Cassandra
- 6. VM VM Гипервизор Контроллерная VM Гипервизор Контроллерная VM Гипервизор Контроллерная VM DEF GHI VM ABCданные данные данные Резервирование данных внутри кластера
- 7. Настраиваемый уровень защиты 100% программно RF-3 защищает от одновременного выхода из строя двух дисков, нодов и сетевых карт Выбор RF-2 и RF-3 Уровень репликации (защиты) выставляется на уровне контейнера Динамическая настройка различных уровней защиты для разных приложений в одном кластере
- 8. VM DEFданные Гипервизор Контроллерная VM Гипервизор Контроллерная VM Гипервизор Контроллерная VM VM ABCданные VM GHIданные VM ABCданные Высокая доступность (HA)
- 9. Резервирование пустей доступа Программное решение Автоматическое переключение на другой виртуальный контроллер в случае сбоя Прозрачно для гипервизора и виртуальных машин Продолжает работать даже если недоступен виртуальный контроллер – обеспечение гарантированной доступности
- 10. Защищает от потери блока целиком (4 cервера / контроллера в кластере одновременно) Доступно начиная с трех блоков Распределение данных между аппаратными блоками Распределение по аппаратным блокам
- 11. Интегрированная защита данных Безлимитные локальные снапшоты с Time Stream Восстановление данных «одним кликом» WAN-оптимизированная репликация для DR Работает с ESXi, Hyper-V и KVM Управление расписанием cнапшотов данных - локальных и «на расстоянии» для целей резервного копирования и восстановления из аварий vdisk Локальные снапшоты Снапшоты в другом ДЦ DR Кластер Основной кластер Локальные бэкапы (вне кластера) Он-сайт вторичные Интеграция с бэкап ПО
- 12. Настройка политик удаления резервных копий локально и на других кластерах (ДЦ) Настройка расписания снапшотов для домена защиты (группы VM) Управление расписанием защиты
- 13. Резервирование данных в облаках – ключевые параметры RTORPO Nutanix Минуты Минуты Time Stream Часы Часы Cloud Connect Ноль Минуты Metro Availability Минуты Минуты Remote Replication Незначительные инциденты Cерьезные инциденты Recovery point objective Recovery time objective
- 14. Аварийное восстановление Гибкая защита Одновременная двунаправленная репликация между дата-центрами (1 to 1, 1 to many, many to many) Модель «мастер-мастер» с множеством путей Сценарии защиты VM Гранулярные снапшоты и политики на каждую виртуальную машину Значительно лучше чем LUN или файловая система Защита данных Восстановление виртуальных машин и приложений Гибкие домены защиты для групп виртуальных машин и их политик
- 15. Metro Availability (синхронные датацентры) Настройка за несколько минут, управляет один инженер Не требуется идентичного оборудования в двух ДЦ До 400 километров (5ms RTT) Любой L3 линк, не требуется темная оптика
- 16. Cloud Connect Nutanix поддерживает резервирование и восстановление данных на облачных провайдеров (в настоящий момент Amazon, в скором будущем Azure и другие).
- 17. Пример • Проект федерального масштаба / государственного значения в РФ (вы точно читали о нем) • Сотни нодов Nutanix, включая «тяжеловесы» • Датацентры, разнесенные более чем на тысячу километров, 10 гигабит связность между ДЦ • Десятки петабайт данных • Круглосуточная загрузка и обработка данных с сотен тысяч объектов • Крайне высокие требования к резервированию и доступности данных и сервисов
Editor's Notes
- The notes section should have a detailed description of how the feature works. De-duplication of data on disk: An administrator can enable disk de-dupe on a container level and/or a vdisk level to reclaim capacity across the cluster. This feature will be available to new as well as existing customers after they upgrade their clusters to NOS 4.0. The feature is disabled by default and has to be explicitly enabled. Once enabled, NDFS deduplicates data in chunks of 4KB blocks (although block size for dedupe is configurable - it works optimally at 4KB). When enabled, upon a write IO request, NDFS calculates and stores SHA01 fingerprint in metadata - data is not deduped at this point. The system performs dedupe when a subsequent read occurs for that data. Curator process scans the data resident on the disks and compares SHA01 fingerprint of the 4KB blocks (which was calculated at the write time and stored along with the metadata). If the fingerprint of a new block matches another existing block, then it updates the metadata to point to the existing block and releases the newly created block. This feature de-dupes data at block level. The block size used by de-dupe is 4KB by default (its configurable). Block Awareness /RF is done at a level below dedupe. So the system has only 2 copies (or 3 copies in case of RF3) of a unique block across the cluster, which are spread over the cluster. Dedupe comes in two flavors - inline and post-process (async). With inline dedupe, there is a performance penalty since it competes with CVM resources (CPU memory) that are being used for servicing user IO at the same time. Whereas, with async/post-processing the performance penalty is minimal. How much CPU/Memory resources of the CVM controller are consumed when de-duplicating disk data? Will we have disk de-dupe inline or post process in Danube? Inline is target. Post process will definitely be there. Inline needs to be turned on for ingest. SE/User should turn it OFF after ingest else performance impact. Which workloads are helped by compression and De-dupe? Can we turn on both compression and De-dupe at the same time? Do we prevent our users to do so at the same time? We do not prevent users to do that from the UI. However, when both are enabled on a container, compression wins today in the backend and de-dupe is disabled. How does de-dupe interoperate with snapshots, backups and quick clones etc.? De-dupe works with snapshots, backups and quick clones. It is not recommended to use de-dupe with shadow clones. Compression and de-dupe? Will prism let them do it? Confirm. They use different block sizes. We don’t recommend mixing both. But the UI lets the user do it. Which workloads should be targeted towards de-dupe and compression? Josh Rodgers: Check best practice. Can a user get any indication of how much space savings he can expect if he enables disk de-dupe on a given Nutanix container before turning de-dupe ON? Dedupe may yield significant savings for workloads (VDI), but may not yield similar returns for all workloads (e.g. server virtualization). Therefore, one should keep this in mind when enabling dedupe for a container/vdisk.
- Seamless HA Metaданные service can access replicas from anywhere New copies are created to ensure continued fault tolerance
- The notes section should have a detailed description of how the feature works. De-duplication of data on disk: An administrator can enable disk de-dupe on a container level and/or a vdisk level to reclaim capacity across the cluster. This feature will be available to new as well as existing customers after they upgrade their clusters to NOS 4.0. The feature is disabled by default and has to be explicitly enabled. Once enabled, NDFS deduplicates data in chunks of 4KB blocks (although block size for dedupe is configurable - it works optimally at 4KB). When enabled, upon a write IO request, NDFS calculates and stores SHA01 fingerprint in metadata - data is not deduped at this point. The system performs dedupe when a subsequent read occurs for that data. Curator process scans the data resident on the disks and compares SHA01 fingerprint of the 4KB blocks (which was calculated at the write time and stored along with the metadata). If the fingerprint of a new block matches another existing block, then it updates the metadata to point to the existing block and releases the newly created block. This feature de-dupes data at block level. The block size used by de-dupe is 4KB by default (its configurable). Block Awareness /RF is done at a level below dedupe. So the system has only 2 copies (or 3 copies in case of RF3) of a unique block across the cluster, which are spread over the cluster. Dedupe comes in two flavors - inline and post-process (async). With inline dedupe, there is a performance penalty since it competes with CVM resources (CPU memory) that are being used for servicing user IO at the same time. Whereas, with async/post-processing the performance penalty is minimal. How much CPU/Memory resources of the CVM controller are consumed when de-duplicating disk data? Will we have disk de-dupe inline or post process in Danube? Inline is target. Post process will definitely be there. Inline needs to be turned on for ingest. SE/User should turn it OFF after ingest else performance impact. Which workloads are helped by compression and De-dupe? Can we turn on both compression and De-dupe at the same time? Do we prevent our users to do so at the same time? We do not prevent users to do that from the UI. However, when both are enabled on a container, compression wins today in the backend and de-dupe is disabled. How does de-dupe interoperate with snapshots, backups and quick clones etc.? De-dupe works with snapshots, backups and quick clones. It is not recommended to use de-dupe with shadow clones. Compression and de-dupe? Will prism let them do it? Confirm. They use different block sizes. We don’t recommend mixing both. But the UI lets the user do it. Which workloads should be targeted towards de-dupe and compression? Josh Rodgers: Check best practice. Can a user get any indication of how much space savings he can expect if he enables disk de-dupe on a given Nutanix container before turning de-dupe ON? Dedupe may yield significant savings for workloads (VDI), but may not yield similar returns for all workloads (e.g. server virtualization). Therefore, one should keep this in mind when enabling dedupe for a container/vdisk.
- The notes section should have a detailed description of how the feature works. De-duplication of data on disk: An administrator can enable disk de-dupe on a container level and/or a vdisk level to reclaim capacity across the cluster. This feature will be available to new as well as existing customers after they upgrade their clusters to NOS 4.0. The feature is disabled by default and has to be explicitly enabled. Once enabled, NDFS deduplicates data in chunks of 4KB blocks (although block size for dedupe is configurable - it works optimally at 4KB). When enabled, upon a write IO request, NDFS calculates and stores SHA01 fingerprint in metadata - data is not deduped at this point. The system performs dedupe when a subsequent read occurs for that data. Curator process scans the data resident on the disks and compares SHA01 fingerprint of the 4KB blocks (which was calculated at the write time and stored along with the metadata). If the fingerprint of a new block matches another existing block, then it updates the metadata to point to the existing block and releases the newly created block. This feature de-dupes data at block level. The block size used by de-dupe is 4KB by default (its configurable). Block Awareness /RF is done at a level below dedupe. So the system has only 2 copies (or 3 copies in case of RF3) of a unique block across the cluster, which are spread over the cluster. Dedupe comes in two flavors - inline and post-process (async). With inline dedupe, there is a performance penalty since it competes with CVM resources (CPU memory) that are being used for servicing user IO at the same time. Whereas, with async/post-processing the performance penalty is minimal. How much CPU/Memory resources of the CVM controller are consumed when de-duplicating disk data? Will we have disk de-dupe inline or post process in Danube? Inline is target. Post process will definitely be there. Inline needs to be turned on for ingest. SE/User should turn it OFF after ingest else performance impact. Which workloads are helped by compression and De-dupe? Can we turn on both compression and De-dupe at the same time? Do we prevent our users to do so at the same time? We do not prevent users to do that from the UI. However, when both are enabled on a container, compression wins today in the backend and de-dupe is disabled. How does de-dupe interoperate with snapshots, backups and quick clones etc.? De-dupe works with snapshots, backups and quick clones. It is not recommended to use de-dupe with shadow clones. Compression and de-dupe? Will prism let them do it? Confirm. They use different block sizes. We don’t recommend mixing both. But the UI lets the user do it. Which workloads should be targeted towards de-dupe and compression? Josh Rodgers: Check best practice. Can a user get any indication of how much space savings he can expect if he enables disk de-dupe on a given Nutanix container before turning de-dupe ON? Dedupe may yield significant savings for workloads (VDI), but may not yield similar returns for all workloads (e.g. server virtualization). Therefore, one should keep this in mind when enabling dedupe for a container/vdisk.
- Whiteboard this.