Hi all,

With automatic configuration, you can configure FlashSystems as external storage to an SVC. Automatic configuration implements optimal virtualization with an SVC based on best practices.

This is intended for new systems.

But existing FlashSystems (behind an SVC) could be reconfigured.
What is the calculation used with automatic configuration to provision all usable capacity in the pool to volumes?

Then we can use this later when recreating volumes.

Thanks.

Hi all,

With automatic configuration, you can configure FlashSystems as external storage to an SVC. Automatic configuration implements optimal virtualization with an SVC based on best practices.

This is intended for new systems.

But existing FlashSystems (behind an SVC) could be reconfigured.
What is the calculation used with automatic configuration to provision all usable capacity in the pool to volumes?

Then we can use this later when recreating volumes.

Thanks.

I'm still curious about how the volumes are calculated, for example, when an FS7300 with 12 FCMs is expanded with 6 or 8 FCMs. Because then automatic configuration is no longer possible.

Hi all,

With automatic configuration, you can configure FlashSystems as external storage to an SVC. Automatic configuration implements optimal virtualization with an SVC based on best practices.

This is intended for new systems.

But existing FlashSystems (behind an SVC) could be reconfigured.
What is the calculation used with automatic configuration to provision all usable capacity in the pool to volumes?

Then we can use this later when recreating volumes.

Thanks.

Hi all,

With automatic configuration, you can configure FlashSystems as external storage to an SVC. Automatic configuration implements optimal virtualization with an SVC based on best practices.

This is intended for new systems.

But existing FlashSystems (behind an SVC) could be reconfigured.
What is the calculation used with automatic configuration to provision all usable capacity in the pool to volumes?

Then we can use this later when recreating volumes.

Thanks.

Hola @T Masteen,

I'd say you can take a look at the redbook "IBM FlashSystem Best Practices and Performance Guidelines", section "3.3.2 Guidelines for creating optimal backend configuration". For instance, I read "For all-flash backend arrays, IBM recommends creating 32 logical volumes from the array capacity", I can confirm such rules are the same if using the Automatic Configuration Wizard. Here an old picture from a very quick test in an FS9500 with 48 FCM I tried some years ago:

Hi all,

With automatic configuration, you can configure FlashSystems as external storage to an SVC. Automatic configuration implements optimal virtualization with an SVC based on best practices.

This is intended for new systems.

But existing FlashSystems (behind an SVC) could be reconfigured.
What is the calculation used with automatic configuration to provision all usable capacity in the pool to volumes?

Then we can use this later when recreating volumes.

Thanks.

Nezih, Luis, thanks for the reply.

The point is that the automatic configuration has already created 32 volumes for the 12 FCMs, plus another 5 volumes for RESERVED_SPACE* (based on a pre-specified compression ratio).
If I now expand the array by 4 FCMs, how does that compare to the existing 37 (32 + 5) volumes? Then the original calculation is no longer correct, right? But perhaps I shouldn't be too fixated on those 32 (best practice).

Hola @T Masteen,

I'd say you can take a look at the redbook "IBM FlashSystem Best Practices and Performance Guidelines", section "3.3.2 Guidelines for creating optimal backend configuration". For instance, I read "For all-flash backend arrays, IBM recommends creating 32 logical volumes from the array capacity", I can confirm such rules are the same if using the Automatic Configuration Wizard. Here an old picture from a very quick test in an FS9500 with 48 FCM I tried some years ago:

Hi all,

With automatic configuration, you can configure FlashSystems as external storage to an SVC. Automatic configuration implements optimal virtualization with an SVC based on best practices.

This is intended for new systems.

But existing FlashSystems (behind an SVC) could be reconfigured.
What is the calculation used with automatic configuration to provision all usable capacity in the pool to volumes?

Then we can use this later when recreating volumes.

Thanks.

I see your point now @T Masteen!

I was thinking about the situation, wouldn't be a simple approach to spread the additional space through the 32 volumes to keep the best practice? For example, let's pretend the expansion of the array gave you 32 more TB, then you can expand each of the 32 volumes by 1TB. That's what came to my mind.

Nezih, Luis, thanks for the reply.

The point is that the automatic configuration has already created 32 volumes for the 12 FCMs, plus another 5 volumes for RESERVED_SPACE* (based on a pre-specified compression ratio).
If I now expand the array by 4 FCMs, how does that compare to the existing 37 (32 + 5) volumes? Then the original calculation is no longer correct, right? But perhaps I shouldn't be too fixated on those 32 (best practice).

Hola @T Masteen,

I'd say you can take a look at the redbook "IBM FlashSystem Best Practices and Performance Guidelines", section "3.3.2 Guidelines for creating optimal backend configuration". For instance, I read "For all-flash backend arrays, IBM recommends creating 32 logical volumes from the array capacity", I can confirm such rules are the same if using the Automatic Configuration Wizard. Here an old picture from a very quick test in an FS9500 with 48 FCM I tried some years ago:

Hi all,

With automatic configuration, you can configure FlashSystems as external storage to an SVC. Automatic configuration implements optimal virtualization with an SVC based on best practices.

This is intended for new systems.

But existing FlashSystems (behind an SVC) could be reconfigured.
What is the calculation used with automatic configuration to provision all usable capacity in the pool to volumes?

Then we can use this later when recreating volumes.

Thanks.

Thank Luis,

That would normally be an option, but this involves a Flash system behind an SVC.
I think I'll be creating 16 new volumes. I don't expect any performance impact. But I thought I'd post it here to see if anyone else has encountered this before.

I see your point now @T Masteen!

I was thinking about the situation, wouldn't be a simple approach to spread the additional space through the 32 volumes to keep the best practice? For example, let's pretend the expansion of the array gave you 32 more TB, then you can expand each of the 32 volumes by 1TB. That's what came to my mind.

Nezih, Luis, thanks for the reply.

The point is that the automatic configuration has already created 32 volumes for the 12 FCMs, plus another 5 volumes for RESERVED_SPACE* (based on a pre-specified compression ratio).
If I now expand the array by 4 FCMs, how does that compare to the existing 37 (32 + 5) volumes? Then the original calculation is no longer correct, right? But perhaps I shouldn't be too fixated on those 32 (best practice).

Hola @T Masteen,

I'd say you can take a look at the redbook "IBM FlashSystem Best Practices and Performance Guidelines", section "3.3.2 Guidelines for creating optimal backend configuration". For instance, I read "For all-flash backend arrays, IBM recommends creating 32 logical volumes from the array capacity", I can confirm such rules are the same if using the Automatic Configuration Wizard. Here an old picture from a very quick test in an FS9500 with 48 FCM I tried some years ago:

Hi all,

With automatic configuration, you can configure FlashSystems as external storage to an SVC. Automatic configuration implements optimal virtualization with an SVC based on best practices.

This is intended for new systems.

But existing FlashSystems (behind an SVC) could be reconfigured.
What is the calculation used with automatic configuration to provision all usable capacity in the pool to volumes?

Then we can use this later when recreating volumes.

Thanks.