It is 2019 now and I have not published anything for over a year.
Granted I don’t think I have any followers but I do hope to start publish more this year.
I have been busy uprooting my family from NZ and migrating to Singapore.
Singapore is a great central hub, I have technical responsibility for Pure Storage FlashBlade high performance file and object sales in ASEAN & Greater China.
I have spent the past almost 18 months getting my head around things and also trying to make a living 🙂
So far things have worked out well, I have put solutions in for solutions for Oracle Data Warehouses, Big Data Analytics Platforms replacing legacy data lakes and AI/ML solutions integrating NVIDIA DGX-1 AI appliances.
In Pure Storage context, these AI solutions are called an AIRI, AI Ready Infrastructure .
Per port queue depths is a common question we hear and how we compare to these limits other vendors publish based on array model.
Pure does not have queue depths assigned on a per port basis and we do not modify the Qlogic HBA per port queue depth of 4096. We also do not issue SCSI “busy” responses back to hosts (instead, we will queue all I/O in the array) there is occasionally some host queue depth adjustments needed for some environments. The goal is to not unnecessarily limit outstanding I/O’s to the array during normal steady state, but also to avoid a situation in cases of massive bursts of I/O from many hosts concurrently.
With legacy mechanical disk arrays, it was important to have as many outstanding I/O’s as possible due to the seeking and rotating going on.
With all flash arrays, and Pure in particular, it is not necessary to keep the queues full and the I/O responses are returned much faster as well, meaning it’s pretty hard to keep the queues full (at least for most organic workloads). One of the key values for Pure is the simplicity – you should not have to do the same types of computations and planning like you are used to with mechanical disk storage. In some cases, there may be some adjustments in aggregate for all hosts connected to the same array to mitigate a IO storm (ensuring host-level fairness), in most cases it is not necessary as we remove the need to do per-port planning.
Vaughn Stewart from Pure Storage recently contributed to a Flash myth busting session with Nimble, Solidfire and EMC hosted by SpiceWorks.
Its well worth the watch at just short of an hour. Answering questions that start out with just what is FLASH, and how does it differ from SSD. I even heard a question about how does Token Ring factor……. not……
Do you want to know what software could possibly shorten the life span of flash? The watch the video
When you decided where to live you had to make some conscious decisions. You had to decide where your house was in relation to things that are important to you – schools, the office, transport hubs, freeways or motorways.
You had to decide based on your method of transport how close you needed to be to those things so that your experience was acceptable or great. If you worked in New York, it would not be practical to live in beautiful New Zealand as the commute just wouldn’t work unless you could work remotely. So location is important for things that are important to you.
Storage works in much the same way. A traditional HDD has many platters and the data is typically accessed on the drive from the inside of the platter to the outside of the platter. Physics is physics so information on the inside smaller section of the platter will be quicker to read/write than information on the larger outside.
Back in the old days, DBAs would have to really think about placement of data. Either by specific spindle and RAID allocation or even getting down to block location on disks. Seek times on the inside of the platter were faster than the outside, so that is where high-performing tables and things like temp-DB needed to live.
Memory has really helped that issue, so has other forms of cache so long as the blocks that need to be cached can fit in the amount of allocated memory or cache, if not you hit a latency wall as you have to go off and seek from disk. This means your reads are essentially free, but writes still require some overhead and I/O tax.
SSD really does go a long way to resolving those issues. SSDs and other flash media are locality reference free! Essentially they are binary charges off and on that means that they are basically free for reads and writes which is why IO latencies are typically sub millisecond.
DBAs now no longer need to worry about where and how they place their data or even if they used share storage. DBAs will always worry, but now they can worry about things further up the stack.
Imagine if you could live in beautiful New Zealand, work in New York and holiday in the Caribbean without the challenges and cost overheads of mechanical travel. That is what locality free data access with SSDs and the right Storage OE can give you.