Developers Club geek daily blog

3 years, 3 months ago
Nutanix Cloud Connect — резервное копирование в «облако» AWS

Начиная с одного из релизов версии 4.1 у Nutanix появилась интересная возможность – Cloud Connect.
Cloud Connect это возможность создать в «облаке» Amazon Web Services (AWS) «виртуальный Nutanix» с дисками, находящимися на EBS+S3, и использовать его как удаленное хранилище резервных копий. Такие штуки сейчас делают очень многие, вот теперь такая возможность есть и у Nutanix.

К сожалению, как я заметил, в России все еще есть серьезное предубеждение против использования публичных и гибридных «облаков» как серьезной бизнес-опции для вашего датацентра. Все еще это считается какой-то «игрушкой», чем-то «несерьезным». Возможно это объясняется характерным для российского IT консерватизмом и традиционным отставанием, когда мировые новости приходят в IT-шную россию изрядно подвяленными, с отставанием на два-три года, или недостаточным знанием новых возможностей, предлагаемых современными облачными провайдерами. Так, например, немногие знают о том, что хорошо известный всем Netflix является полностью «безСХДшной» компанией. Все хранилище для бесконечных тысяч сериалов и видеофильмов Netflix расположено на пространстве, арендованном в облаке AWS.
Так что, очевидно, встроенные средства интеграции с публичными облачными провайдерами в оборудовании хранения и обработки данных, ждет большой спрос. Вот почему Cloud Connect в Nutanix это интересная, но пока все еще недостаточно оцененная возможность, именно поэтому я и собрался о ней сегодня рассказать.

Cloud Connect встроен в наш HTML5-интерфейс управления Nutanix Prism UI. Для начала вам нужно будет указать ваши реквизиты доступа к среде AWS из IAM (AWS Identity and Access Manager).

Nutanix Cloud Connect — резервное копирование в «облако» AWS

Далее Cloud Connect создаст на «той стороне» виртуальный Nutanix в виде «однонодового» кластера, знакомого тем, кто уже попробовал наш Community Edition, где эта возможность также есть. Следует понимать, что мы используем в AWS однонодовую конфигурацию без «отказоустойчивости средствами Nutanix», потому что отказоустойчивость наших данных обеспечивается на стороне AWS, и нет нужды их дублировать.

Затем вы можете выбрать нужный вам регион EC2, установить VPN канал к вашему экземпляру «виртуального Nutanix в облаке AWS» (мы уже подготовили и установили в репозиторий AWS нашу AMI, виртуальную машину с NOS внутри), и сделать прочие настройки.

Nutanix Cloud Connect — резервное копирование в «облако» AWS

И на этом – все.

Nutanix будет самостоятельно реплицировать снэпшоты указанных вами данных вашей системы на удаленное хранилище. Причем, обратите внимание, это важно. Бэкап будет реализован с помощью снэпшотов, то есть, после первоначальной синхронизации, на удаленную систему будут передаваться только diff-ы состояния указанных данных, вдобавок в сжатом на лету, для уменьшения объема передачи и хранения виде.
Для размещения данных используется как EBS, Elastic Block Storage, быстрое блочное хранилище, которое мы разместили на SSD tier и используем, как и в «большом» Nutanix для хранения метаданных «виртуального Nutanix», так и недорогое (но сравнительно медленное) хранилище AWS S3 (Simple Storage Service).

И разумеется, такой «виртуальный Nutanix» может использовать любые средства репликации, включая «один ко многим» и «многие к одному» для синхронизации меду различными регионами AWS.

На испытаниях мы достигали потока передачи резервной копии в 200 мегабит в секунду. Теоретический предел – 500, но часть ресурсов съедается на обработку SSL/TLS между EBS и S3.

А теперь давайте посмотрим, во что же нам обойдется такой бэкап по деньгам.
Для использования Cloud Backup нам понадобятся:
  • Инстанс EC2 типа m1.xlarge, для установки на него «виртуального Nutanix» в среде AWS, принимающего резервные копии.
  • Том EC2
  • Бакет (bucket) S3
  • VPN к виртуальной машине.

Точный калькулятор со свежими ценами на момент, когда вы будете читать это пост, вы можете взять тут: calculator.s3.amazonaws.com/index.html
На сегодня это выглядит так:
  • EC2 m1.xlarge стоит 0.35$/час, это 252$ в месяц.
  • 200GB том на SSD для нашего инстанса, для хранения метаданных, стоит 20$ в месяц.
  • Снэпшоты – еще 30$ в месяц
Итого на EC2 инстанс – 302$/месяц.

VPN шлюз к нашему VPC.
  • VPN Gateway to VPC – 0.05$/час, или 36$ в месяц.

Бакет S3 для хранения данных бэкапа.
  • Текущие цены – 0.033$ за гигабайт хранения в месяц.

Предполагаем, что содержимое резервной копии сжимается вдвое, достаточно близкая к правде оценка, и возьмем, для простоты, емкость в 1TB, то есть хранить мы будем 500GB на S3. Это даст нам 17$ в месяц.
Трафик восстановления будет стоить нам 0.02$/GB, но так как мы будем на Nutanix восстанавливать данные в виде и объеме снэпшотов, а не весь хранимый объем целиком, то эти затраты будут скорее всего невелики, и зависеть от частоты восстановлений данных.

Итого, хранение 1TB несжатых данных в облаке AWS нам будет стоить 302$ EC2 + 36$ VPN + 17$ S3 = 355$ в месяц. Причем обратите внимание, что при этом подавляющая доля цены пришлась на нашу виртуалку EC2 (можно ли ее держать не все время включенной? Ну, в общем – да, такой «виртуальный Nutanix» вполне можно поднимать на время создания резервной копии и останавливать сразу после). То есть, если нам понадобится хранить 10TB, то тогда этот объем будет стоить всего 170$ в месяц, плюс все те же 302$ и 36$, а если 100TB, то – 1700$. Вдобавок, мы можем легко использовать преимущество «облака». Если сегодня нам нужно хранить 1TB бэкапов, через месяц – 50TB, а через полгода снова 2-3TB, то в случае своей инфраструктуры вам придется заводить хранилище емкостью «по максимуму, плюс еще запас на непредвиденное», то в случае AWS – просто арендуете ровно тот объем, который займут данные, добавляя и убирая по мере возникновения в нем надобности.

Так что вариант вполне достойный рассмотрения, если ваш интернет-канал до точек присутствия AWS в мире достаточен для комфортного копирования и, более важно, восстановления данных. А у кого-нибудь уже есть опыт использования AWS как сайта хранения удаленной копии? Какой скорости передачи данных вы достигали?

This article is a translation of the original post at habrahabr.ru/post/263739/
If you have any questions regarding the material covered in the article above, please, contact the original author of the post.
If you have any complaints about this article or you want this article to be deleted, please, drop an email here: sysmagazine.com@gmail.com.

We believe that the knowledge, which is available at the most popular Russian IT blog habrahabr.ru, should be accessed by everyone, even though it is poorly translated.
Shared knowledge makes the world better.
Best wishes.

comments powered by Disqus