Раньше я задавал вопрос по этой теме, но теперь я предпочитаю переписать ее с нуля, потому что тогда я был очень запутан.
В настоящее время у меня есть роль виртуальной машины Linux XS в Azure. В основном я хочу создать самоуправляемую и развивающуюся службу хостинга с использованием виртуальных машин, а не более дорогих веб-ролей Azure. Я также хочу воспользоваться преимуществами балансировки нагрузки (между ролями виртуальных машин) и георепликации (ролей хранилища), убедившись, что «веб-файлы» клиентов находятся в определенном и управляемом месте.
Один из способов, который я нашел для "монтирования" диска в виртуальной машине Linux, описан. Вот и включает установку VHD на виртуальную машину. Из того, что я мог узнать, VHD надежно хранится в роли хранилища и блокируется исключительно виртуальной машиной, которая его использует. Как только у роли виртуальной машины появится диск, я могу отформатировать раздел до любого размера. Я не хочу этого !!
Я хотел бы, чтобы у каждого размещенного сайта был свой собственный каталог blob, а затем каждая реплицированная / сбалансированная по нагрузке роль виртуальной машины для монтирования rw, как в NFS, этот каталог blob для чтения файлов HTML и скриптов. База данных явно любезно предоставлена Microsoft :)
Возможно ли на самом деле mount хранилище BLOB-объектов в каталог в Linux FS? Возможно ли это в Windows Server 2008?
Недавно Microsoft представила Общие папки Azure
Это крепления CIFS / SAMBA в Linux. Итак, ссылка выше является правильный ответ с мая 2014 г.
Во-первых, некоторые пояснения, которые помогут вам развеять сомнения.
Хорошо, сказав все это: инструкции, которые вы нашли по подключению диска к виртуальной машине Linux, показывают, как делать что-то через портал (и вы можете сделать то же самое со сценариями командной строки). Всего можно установить до 16 дисков (2 на ядро и 1 на XS). Каждый смонтированный диск рассматривается как целая файловая система.
Если вы хотите, чтобы каждая виртуальная машина имела свой собственный диск, вы можете подключить соответствующий диск (и) к каждому (опять же, до 16 на виртуальную машину). После того, как диск смонтирован, эта виртуальная машина получает эксклюзивный доступ для записи на диск (без совместного использования диска). Это не зависит от ОС: такое же ограничение в Win28K, Linux или даже в роли web / worker / vm. Итак: в модели, где обслуживает каждая виртуальная машина только один сайт, это помогает. В модели, где обслуживает каждая виртуальная машина все сайты, это не совсем помогает в том, что вы пытаетесь сделать. Так...
Если вы выполняете балансировку нагрузки между двумя виртуальными машинами, и им обоим нужен доступ к одному и тому же статическому контенту (например, контенту веб-сайта), следует учитывать одну вещь: хранить статический контент непосредственно в большом двоичном объекте (в виде zip / tar) или серии капель в контейнере. Затем, при загрузке (или при получении сигнала какого-либо типа), пусть виртуальная машина (-ы) загрузит указанный (-ые) объект (-ы) в локальное хранилище. Этот метод предоставляет вам центральное место для хранения вашего веб-контента. Вы также можете хранить их на диске Azure, но я не вижу в этом смысла: тогда вам придется беспокоиться о том, чтобы использовать только для чтения снимки диска, а затем смонтировать снимок. Похоже, много дополнительной работы по сравнению с простым захватом файлов из хранилища BLOB-объектов.
Между прочим: операции копирования будут регулироваться размером виртуальной машины. Пропускная способность сети на виртуальной машине составляет 100 Мбит / с на ядро, но для XS только 5 Мбит / с. В зависимости от того, сколько данных вы копируете из хранилища BLOB-объектов на локальный диск, это может показаться немного медленным с XS. Да, и пропускная способность между хранилищем BLOB-объектов и вашей виртуальной машиной бесплатна в одном центре обработки данных.
Надеюсь, это ответит на ваш вопрос ...
Возможный ответ (еще предстоит оценить на предмет осуществимости)
Вариант мог быть fuse файловая система. Я нашел Файловая система REST для FUSE и @David Makogon только что подтвердил мою мысль, что хранилище BLOB-объектов было не более чем службой REST