Welcome to Azure. Blobs

Капля никотина убивает лошадь, а хомячка разрывает на куски …

Школьная страшилка

---

Про сервисы хранения данных мы уже с Вами, и я уже рассказывал что их есть три типы блобы, таблички и очереди. Каждая из них может быть использованна для разных нужд. К примеру в табличках мы можем хранить статистические данные которые необходимы для создания репорта, или же мы можем там хранить информацию о товарах в магазине; в очереди мы можем хранить строчки, сосбтвенно хранением это назвать тяжело — скорее пересылкой сообщения от роли к роли; и вот наконец-то блобы — самые большие, объемные и больше всего подходящие под хранение файлов, музыки, видео, чего угодно. Именно блобы лучше мспользовать как аналог файловой системы для всего приложения. Итак, все потихоньку!

Blobs (далее блобы, чтобы часто не переключать клавиатуру) — это аббревиатура от Binary Large OBjects. В самом начале блобы появились в реляционных базах данных, и использовались для хранения файлов в табличке, собсвтенно с такой же идеей они и перекочевали в Ажур.
Мне очень нравится как главу про блобы начинает автор книги «Azure in Action»:

«No matter what hat I put on (Author, Presenter, Architect, Developer or Computer Scientist) I am embarrassed
about the following statement. Sharing files across machines is errrghh, hard. Really, it is, it shouldn’t be (it
really shouldn’t), but it is. Decoding the Genome and making robots climb stairs, that should be hard but not
this, not sharing files that just shouldn’t be hard.»

Идея проста, автор выражает свою обиду на изречение, которое гласит что шарить файлы для кучи машин — сложно.

Давайте предположим, что у Вас есть приложение которое использует много файлов ( к примеру видео), при этом у вас есть несколько серверов на которых висит Ваше приложение. Естественно что логичная структура — это когда все необходимые фалы лежат на отдельном компьютере, все сервера имеют доступ к этому месту, и все проводят операции с файлами с одного места. Теперь представим какие вопросы возникают при реализации:
1.А места то у нас хватит чтобы хранить все файлы? Понятно, что когда Ваш сервис только начал свою работу — места хватит, а если видео будет постоянно добавляться?
2. Естественно Вам прийдется расширять хранилища данных для своего сервиса. Теперь подумайте — как? Ответ на этот вопрос должен быть заложен ещё до начала старта Вашего проекта.
3. Вам надо подумать над тем — что случиться если винчестер на одном из серверов вдруг загнется. Представте Ваши пользователи закачивали гигабайты информации на Ваш сервис, а в следствии скачка напряжения — сгорел хард. Вам стоит поставить вопрос дупликации или бекапа данных. При чем , если вдруг одно хранилище данных выйдет из строя — другое тут же должно быть подключенно! При чем так как оно стало основным — его тоже стоит бекапить!
4. Представте теперь что количество пользователей Вашего сервиса некулонно растет — Вам прийдется решать проблемы со скоростью доступа к данным. Один сервер с данными врятли потянет тысячу запросов одновременно.

Это четыре вопроса навскидку, теперь подумайте — сколько вопросов прийдется решать уже после запуска проекта! Хорошая новость — решения есть:) Плохая новость — чем дешевле решение , тем менее гибким оно является.

Как все уже поняли — вдохновение я черпаю с книжки «Azure in Action», собственно все мои посты — это интерепретация глав этой книжки. И мне показалось прекарсной идеей то, что в книге ребята разместили решения которые используются не в облачных средах. Итак, как же решаются такие проблемы на земле бренной, без облаков:

1. SQL Server . Достаточно распространенное решение — в этом случае база данных используется как хранилище данных. Если использовать только базу данных — существует огромная вероятность того, что при падении сервера с базой данных — завалится все! Тоесть, чтобы быть более отказоустойчивыми Вам прийдется использовать такие страшные вещи как репликация, кластеризация и т.д. При усложнении решения — цена растет. Собственно, если Вы собираетесь хранить видео — база не самый лучший выбор — дорого и порблем не оберешся.

2. Сетевая шара. Наверное самое дешевое и легкое решение — есть сетевой диск, или сетевой ресурс, куда все могут доступаться. Проблема опять же , в том что система не особо отказоустойчева — если кто-то прольет кофе на физический девайс — все, привет вашему сервису:)

3. DFS ( Distributed File System) — вот тут уже интереснее. Windows 2003 — 2008 уже содержат в себе такую фичу. Это P2P решение. Все Ваши фаловые хранилища соедененны в одну ферму, когда файл записывается на один из серверов —
он паралельно синхронизируется на другой сервак. Потому, если одна из машин отвалится, то все файлы будут доступны на другом сервере. Вообщем то это решение чаще используется на Linux системах.

4.NAS (Network Attached Storage) -это уже больше хардварное решение — это такая себе «гроздь» хардов, к которым можно доступаться как с розшаренному хранилищу данных. Цена одного такого девайса очень колеблется, и может быть как недорогой так и очень дорогой. Все зависит от разширяемости, и других параметров.

5.DAS (Direct Attached Storage) — так же хардварное решение, очень похожее на NAS. Этот девайс вставляется в сервер, и воспринимается сервером как локальный диск. Ограниченны мы только возможностями нашего сервера менеджить максимальные размеры хранилища. Это для домашних компьютеров — 100 ТБ это много, для больших видео хостингов — семочки:)

6.SAN (Storage Attached Network) — самое дорогое решение, которое простым смертным не по корману:) Собственно это целый шкаф хардов, у которых даже опреационки то нету, воспринимается это все счастье как виртуальные диски, подключенны они через fiber channel.

Fibre Channel (FC) — семейство протоколов для высокоскоростной передачи данных. Стандартизацией протоколов занимается Технический комитет T11, входящий в состав Международного комитета по стандартам в сфере ИТ (InterNational Committee for Information Technology Standards — INCITS), аккредитованного Американским национальным институтом стандартов (ANSI). Изначальное применение FC в области суперкомпьютеров впоследствии практически полностью перешло в сферу сетей хранения данных, где FC используется как стандартный способ подключения к системам хранения данных уровня предприятия.

Wikipedia(C)

Это счастье очень расширяется, но чтобы его запустить нужно иметь специфические знания, много денег и времени. В основном используется на крупных ентерпрайзах.

Ну что, по моему и так понятно, что для того чтобы развернуть любое из решений у себя дома, нам понадобится:
1. Админ, как минимум 1. Админы по странному обычаю любят есть, пить, и получать зарплату.
2. Менеджера который будет говорить что админу делать. Тоже любит деньги.
3. Постоянные покупки железок, софта, ремонты.

Теперь после такого длинного вступления давайте обратим свой взор на блобы:)

Чтобы не мучать нас проблемами доступа, Микрософт выпустили сервисы хранения данных к которыми мы можем обратиться через HTML по REST API.
Тут, кстати, интересная штука возникает — если вы попытаетесь скачать большое количество данных с Ажура себе на компьютер — Вы будете ограниченны скоростью интернета, потому закачка будет просиходить долго, хотя в тоже время, если вы будете копировать данные в середине ажура — все закончиться через несколько секунд.

Масштабируемость
Блобы построены на основе веб ролей. Про то как они отлично масштабируются мы уже с Вами говорили!

Дисковое хранилище
Я думаю и ежу понятно что дискового хранилища в Ажуре очень много. Если места будет не хватать — Микрософт всегда добавит больше жестких дисков, только чтобы у нас хватило места. К блобам мы можем относиться как к бесконечному винчестеру. Вот тут главное чтобы возможности не затмили рассудок — это все стоит деньги:) Помните, как я любил ставить ударение на фразе: Мы платим только за то что мы используем.

Репликация
Каждый байт вашей инофрмации которую вы записываете в сервисы хранения данных реплицируется 3!!! раза ( это бесплатно:) тоесть если вы платите за 10 гигабайт — на самом деле это 30 гигабайт! 20 отдано на репликацию .) Тоесть Вы каждую минуту времени можете быть на 100 процентов уверенны, что Ваши данные не пропадут, и даже если в датацентре случиться пожар ( привет, hosting.ua ) Вы не потеряете данных.

Скорость
Ну чего греха таить — если вы исопльзуете дорогие решения в собсвенно дата центра ( или даже в приватном облаке ) скорость будет быстрее. Этот расплата за отказоустойчивость , репликацию, и другие вкусности которые у нас есть, и мы не волнуемся о том кто и как это настроит. Если Вам необходимо записать большие объемы данных — блобы прекрасное место хранилища этих данных (в следующем посте мы с Вами поговорим про два типа блобов), но если Вам необходимы данные которые вы постоянно обновляете, или получаете очень часто — то их скорее стоит сохранить в локальном хранилище данных.

Менеджмент
Ну вот мы уже с Вами обсуждали что необходимо для того чтобы наш сервис мог безболезненно хранить много информации если не использовать облака. Теперь подумаем от каких затрат мы избавляемся при использовании Ажура:
1. Так как всем этим счастьем заправляет фабрика, нам теперь не нужен дорогой администратор — Микрософт кормит своих сами.
2. Чтобы построить систему которая будет масштабируемая, отказоустойчевая — на мнужно содержать большую инфарасктруктуру. Вы не подумайте, что это только железки — это и охлаждение, и электричество, и конечно же строение где наши сервера будут стоять. Все теперь на стороне Микрософта, пусть сами и разбираются. Мы тратим наше время и ресурсы на раскручивание нашего сервиса!
3. А ведь оборудование тоже ломается, тем более в нашей стране с перепадами напряжения, и его стоит заменять. А для того чтобы его заменить — его в начале нужно купить. И даже эту нагрузку Микрософт берет на себя. За что им большое спасибо, и оплата ихних сервисов:)

Тоесть как видите плюсков несказанно больше. Вообще я заметил тенденцию, что сервиса хранения данных очень часто используются в многих больших веб проектах. И это очень понятно — потому как данные в любом случае прийдется хранить — будь то картинка, или же видео. Одним из конкурентов Ажура естественно является Amazon S3. Тоже очень хороший сервис , между прочим, его использует DropBox для хранения Ваших файлов. Но есть у него одна проблема — иногда когда мы хотим выкачать оттуда файл, который только что положили — Амазон заявляет что такого файла нету, и никогда небыло. Все решается просто — надо попросить Амазон этот файл ещё раз, и он его таки отдаст. Собака зарыта в том, что когда вы записываете файл на сервера Амазона — они сохраняются на компьютере, и начинают синхронизироваться с другими серверами. Легко догадаться, что после того как мы залили файл, наш запрос может быть перенаправлен на другой сервер, на котором файла ещё нету. В Ажуре эту проблему решили просто и сердито — данные реплицируются не в тот момент, когда файл записанн, а сразу в три разных источника. Все гениальное — просто!

На сегодня все, в слудеющем посте мы взглянем что такое блобы поближе, научимся ими управлять, и показывать с ними всяческие фокусы.

---

Полезные ссылки:
http://www.microsoft.com/windowsserversystem/dfs/default.mspx — Что такое DFS и с чем его едят.

http://en.wikipedia.org/wiki/Network-attached_storage — тоже самое, но про NAS.

http://en.wikipedia.org/wiki/Direct-attached_storage — Direct Attached Storage. Базовая информация

http://en.wikipedia.org/wiki/Storage_area_network — статья с вики о том что такое Storage Area Network. Я хоть и не администратор, но почитать достаточно интересно. Советую.

http://msdn.microsoft.com/en-us/library/dd179355.aspx — Windows Azure Storage Services REST API Reference

http://www.thestoragearchitect.com/2010/01/07/virtualisation-windows-blob-storage-vs-amazon-s3/ — отличная статья про сравнение Amazon S3 vs Azure Storage Services

http://gladinet.blogspot.com/2009/12/windows-azure-blob-storage-vs-amazon-s3.html — ещё одна статья. Можна сделать вывод что оба хранилища данных идут ноздря в ноздрю, и это отлично — чем больше провайдеров — тем быстрее равзивается технология!