Create a Fabric capacity in a different Azure region from the tenant, impacts?

[vivien57]

Hello everyone,

I would like your opinion on this subject.

We have a tenant in the Azure "North Europe" region.

For some time now, it has been decided that all the Azure services we deploy in the future will have to be deployed in "West Europe".

We are now preparing to buy Fabric F64 capacity, and obviously we have a small warning if we select "West Europe" for the capacity because the PowerBI/Fabric tenant is in "North Europe".  So it warns us that we're in a multi-geo situation.

After some research, moving the tenant from "North Europe" to "West Europe" is something complex and important that only the Microsoft teams can do.

So we're thinking of creating a capability that's in a different region to the tenant (despite the fact that we're not in an international context and so it would normally be more practical to have both in the same regions).

However, I find it hard to measure all the impacts this could have, in terms of unavailable features, performance, cost (transfer between regions), etc...

Do you have any information (other than the official Microsoft documentation) or feedback on this subject ?

If not, has anyone tried migrating a tenant from one region to another ?

Thanks in advance for your return,

Have a nice day,

Vivien

[Anonymous]

Hi @vivien57,

In my opinion, migrating tenant should not a good choice and operations. They are complex and obviously effect more of feature usages. 

For your scenario, I'd like to suggest you migration the workspace hosted fabric capacity data region insead.

Configure Multi-Geo support for Fabric#Enable and configure 

BTW, I think in official document considerations and limitations part already mention the Multi-Geo for fabric capacity usage scenarios and limitations, you can take a look on it if helps:

Multi-Geo support for Fabric - Microsoft Fabric | Microsoft Learn

Spoiler

Considerations and limitations

• Confirm that any movement you initiate between regions follows all corporate and government compliance requirements prior to initiating data transfer.
• Cached data and queries stored in a remote region stays in that region at rest. Additionally, the data at rest is replicated to another region in the same Azure geography for disaster recovery if the Azure geography contains more than one region. Data in transit might go back and forth between multiple geographies.
• The source data might remain in the region from which the data was moved for up to 30 days when moving data from one region to another in a Multi-Geo environment. During that time end users don't have access to it. It's removed from this region and destroyed during the 30-day period.
• Query text and query result traffic for imported and DirectQuery data models doesn't transit through the home region. The report metadata does still come from the home region, and certain DNS routing states might take such traffic out of the region.
• Certain features such as screenshots, data alerts and others will still process data in the home region.
• The detailed semantic model metadata that is cached as part of enhanced metadata scanning is always stored in the home region, even if the scanned semantic model is located in a remote region.
• The dataflows feature isn't supported on Multi-Geo at this time.
• It's possible to create and maintain large-storage format semantic models in remote regions to meet data residency requirements. However, you can't move storage format semantic models to another region. Moving large-storage format semantic models from the region where they were created results in reports failing to load the semantic model. Move the large-storage semantic model back to its original region to make it available. If you must move such a model, deploy it as if it was a new model, and then delete the old model from the undesired region.
• Multi-Geo doesn't support Metrics in Power BI.

Regards,

Xiaoxin Sheng

[vivien57]

Hello,

Thank you for your reply. I had already found this information. However, I'm not convinced that these are the only impacts.

In fact, as some data remains in the Azure tenant region, and some data in the capacity region, there are data transfer costs between these two regions, right?

In addition, some Workspaces will still be in Pro, which means that this data will be stored in an Azure region, whereas data with a Worksapce on capacity will be stored in another Azure region.

My other question is that there's only one OneLake per tenant. If we have capacity in 3, 4 or 5 regions, will the OneLake data be stored? According to the location of the different capacities? In other words, the OneLake storage will be split into several locations?

Thanks in advance for your return,

Have a nice day,

Vivien

[Anonymous]

HI @vivien57,

>>In fact, as some data remains in the Azure tenant region, and some data in the capacity region, there are data transfer costs between these two regions, right?

Yes, this feature moves some of used data to the remote region to reduce the delay of the operations.

>>My other question is that there's only one OneLake per tenant. If we have capacity in 3, 4 or 5 regions, will the OneLake data be stored? According to the location of the different capacities? In other words, the OneLake storage will be split into several locations?

I'd like to suggest you take a look at the architecture of the onelake. These data are hosted to the onelake platform, and detail contents can be group by workspace and managed by different data regions.

OneLake, the OneDrive for data - Microsoft Fabric | Microsoft Learn

If these not fully suitable with your requirement, you can consider to submit idea for improve this feature.

Regards,

Xiaoxin Sheng