# Azure Blob Storage - Using Blobfuse2

**URL:** <https://discuss.elastic.co/t/azure-blob-storage-using-blobfuse2/357932>\
**Category:** Elasticsearch\
**Created:** [April 22, 2024, 5:37pm UTC](https://discuss.elastic.co/t/azure-blob-storage-using-blobfuse2/357932 "2024-04-22T17:37:22Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![erikg](https://avatars.discourse-cdn.com/v4/letter/e/91b2a8/32.png) [@erikg](https://discuss.elastic.co/u/erikg)\
**Post date:** [April 22, 2024, 5:37pm UTC](https://discuss.elastic.co/t/azure-blob-storage-using-blobfuse2/357932/1 "2024-04-22T17:37:22Z")

</div>

Hello,  
We are currently running self-managed Elastic using Azure VMs.  
Due to vast amount of data ingested, 100TB+ we are leveraging Azure's premium disks for our cold and hot data nodes.

We are trying to move away from the premium SSDs , and are considering Azure Blob Storage. There seems to be a way to do this using [BlobFuse2](https://github.com/Azure/azure-storage-fuse).

I am wondering if this is possible to replace **SSD Managed Disks** with **Azure Blob Storage** for hot and cold data nodes?

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [April 23, 2024, 6:50am UTC](https://discuss.elastic.co/t/azure-blob-storage-using-blobfuse2/357932/2 "2024-04-23T06:50:48Z")

</div>

See [these docs](https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-node.html#data-path):

> The contents of the `path.data` directory must persist across restarts, because this is where your data is stored. Elasticsearch requires the filesystem to act as if it were backed by a local disk, but this means that it will work correctly on properly-configured remote block devices (e.g. a SAN) and remote filesystems (e.g. NFS) as long as the remote storage behaves no differently from local storage. You can run multiple Elasticsearch nodes on the same filesystem, but each Elasticsearch node must have its own data path.
> 
> The performance of an Elasticsearch cluster is often limited by the performance of the underlying storage, so you must ensure that your storage supports acceptable performance. Some remote storage performs very poorly, especially under the kind of load that Elasticsearch imposes, so make sure to benchmark your system carefully before committing to a particular storage architecture.

In my experience FUSE-based filesystems fail to satisfy the "behaves no differently from local storage" constraint, and also tend to have pretty poor performance overall, but I've never used this particular one.

The best approach would be to use [searchable snapshots](https://www.elastic.co/guide/en/elasticsearch/reference/current/searchable-snapshots.html) - this feature is specifically designed to make the best use of blob storage.

---

<div class="post-metadata">

**Author:** ![erikg](https://avatars.discourse-cdn.com/v4/letter/e/91b2a8/32.png) [@erikg](https://discuss.elastic.co/u/erikg)\
**Post date:** [April 23, 2024, 2:33pm UTC](https://discuss.elastic.co/t/azure-blob-storage-using-blobfuse2/357932/3 "2024-04-23T14:33:15Z")

</div>

Thanks. It seems like the searchable would be useful, but it requires an Enterprise license.

---

<div class="post-metadata">

**Author:** ![DavidTurner](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/davidturner/32/22453_2.png) [@DavidTurner](https://discuss.elastic.co/u/DavidTurner)\
**Post date:** [April 23, 2024, 2:37pm UTC](https://discuss.elastic.co/t/azure-blob-storage-using-blobfuse2/357932/4 "2024-04-23T14:37:22Z")

</div>

That's true, this feature does cost money, but the opex cost savings will more than offset those costs.