FlashPool was almost miraculous in its day, and it's still important. I've seen a bit of a resurgence for FlashPool in the past year for similar reasons to what you seem to have. We see these massive archival systems, and I'm strongly recommending generous FlashPool so whatever random IO might happen will be captured by the SSD layer.
I spent years building database setups, and if I could get 5% of the total dataset size in the form of FlashPool SSD, then virtually all the IOPS would hit that SSD layer. There was often barely any difference between all-flash and Flashpool configurations. There would still be a lot of IO hitting the spinning drives, but it was the sequential IO, which honestly doesn't benefit much from SSD anyway.
That approach mostly went out the window because all-flash got affordable. Even if you didn't technically need all-flash at the moment, it was cheap enough and futureproof. A second reason is the size of spinning drives. We used to regularly sell systems with eight SSDs and 500 spinning drives. There was a decent amount of spinning disk IOPS to go around. These days, you're often buying dramatically fewer spinning drives, which means it's easier to push them to their collective IOPS limits. FlashPool can be a nice cushion against IO surges.
I'd also recommend taking a look at C-Series. The whole point of C-Series is all-flash capacity projects. It's the natural upgrade path for hybrid SSD systems. I don't know what price looks like. Some customers are definitely swapping hybrid for C-Series, but there are also some huge capacity projects where that doesn't quite make financial sense.
Someday, though. Someday there will be no hybrid spinning disk systems and it will all be on these capacity-based all-flash systems, but there is still a role for FlashPool at present.
-------- Original Message -------- Subject: Re: Question about flash pool maximum SSD size and local tiering Date: Tue, 17 Oct 2023 14:12:28 +0000 (UTC) From: Florian Schmid fschmid@ubimet.com To: Michael Bergman michael.bergman@norsborg.net CC: Toasters toasters@teaparty.net
Hi Michael,
wow, thank you very much for your time writing this very detailed explanation!
It will be one 2-node 8300 cluster, switchless. The cluster will be mainly used for long time archive storage until it is going to tape or for tape restores. For this, we want to take a huge amount of NL-SAS drives.
I thought for speeding the NL-SAS aggregates a little bit up, we also use some SSDs as flash-pool, like we have it now on our old dev NetApp cluster.
The other SSDs will be used for backup and DR purposes. We have a full production all-flash cluster for our normal workloads.
We think about moving some data to the 8300 cluster in the long term, because not all volumes we have now on SSD must be on flash and might consume there too much "expensive" space.
I will also have a deeper look on fabricpool. I had a look already on it in the past, but as I read S3 storage, I haven't looked deeper into it, as we are not using S3 at all in the moment. This was some years ago. As we always had only one all-flash cluster, I haven't thought about it.
Should fabricpool not also work on a 2-node cluster? So instead of using some SSDs for flashpool, we could create an aggregate on SSD and one on NL-SAS and use the NL-SAS one for S3 storage and then for local fabricpool?
Best regards, Florian _______________________________________________ Toasters mailing list Toasters@teaparty.net https://www.teaparty.net/mailman/listinfo/toasters