Монтирование контейнера блоба Azure в Роли VM Linux

Вы могли бы контроль с помощью rsync для локального резервного копирования

1
задан 5 September 2012 в 21:30
3 ответа

Недавно компания Microsoft представила Azure Shared Folders

Это CIFS/SAMBA крепления в Linux. Таким образом, вышеуказанная ссылка является правильным ответом с мая 2014 года

.
4
ответ дан 3 December 2019 в 16:27

First, some clarifications, to help you further unconfuse yourself.

  • Your linux instances are considered Virtual Machines. These are different from the existing VM Role. The former is a vhd you manage in your storage account, and supports several OS variants. The latter is something you create locally, upload to Windows Azure (into storage not managed by you), then spawn one or more instances of that VM Role (which works similarly to web/worker roles). Just wanted to clarify, as you refer to your linux VM as "VM Role."
  • Web roles (or worker roles, or VM Roles), are not more expensive than Virtual Machines. They all get metered at an hourly rate, per core, at a list price of $0.12 / hour (or $0.02 / hour for XS).
  • Storage is a service, not a role. Web / worker / vm "roles" are essentially templates (or scaffolding) for the code that runs in the virtual machine instances, aside from the code you deploy. Storage is a REST-accessible service.

Ok, having said all that: The instructions you found about mounting a drive to a linux Virtual Machine show how to do things via the portal (and you can do the same thing with command-line scripts). You can mount up to 16 total drives (2 per core, and 1 on an XS). Each mounted drive is treated like an entire file system.

If you wanted each Virtual Machine to have its own drive, you can mount the appropriate drive(s) to each (again, up to 16 per Virtual Machine). Once a drive is mounted, that Virtual Machine has exclusive write access to the drive (no drive-sharing). This is independent of OS: Same restriction in Win28K, Linux, or even a web/worker/vm role. So: In the model where each Virtual Machine serves only one website, this helps. In the model where each Virtual Machine serves all websites, this doesn't really help with what you're trying to do. So...

If you're load-balancing traffic between two Virtual Machines, and they both need to access the same static content (e.g. website content), one thing to consider: Store static content directly in a blob (as a zip/tar) or series of blobs in a container. Then, upon bootup (or some type of signal), have the Virtual Machine(s) download said blob(s) to local storage. This method provides a central place for you to store your web content. You could also store them in an Azure drive, but I don't really see the value in doing so: You'd have to then worry about taking read-only snapshots of the drive, then mounting the snapshot. Seems like lots of extra work, vs just grabbing files from blob storage.

By the way: The copy operations are going to be throttled by Virtual Machine size. Network bandwidth on the Virtual Machine is 100Mbps per core, but for XS, only 5Mbps. Depending on how much data you'd be copying from blob storage to local disk, this could seem a bit slow with XS. Oh, and bandwidth between blob storage and your Virtual Machine is free within the same data center.

Hopefully this answers your question...

4
ответ дан 3 December 2019 в 16:27

Возможный ответ (еще предстоит оценить на предмет осуществимости)

Возможным вариантом может быть fuse файловая система. Я нашел файловую систему REST для FUSE и @David Makogon только подтвердил мою мысль о том, что хранилище BLOB-объектов было не более чем службой REST

0
ответ дан 3 December 2019 в 16:27

Теги

Похожие вопросы