I’m going to start this blog with some non-technical observations about cycles and history. For those of us old enough to span multiple eras of fashion, music and technology we begin to see some familiar attributes emerge and be presented as “new”. We hear familiar riffs in a brand-new song, we see new fashions emerge which look exactly like the trends 30 years ago (I’m still waiting for parachute pants to come back).
Are these trends “exactly” like the originals? No, they are different in many ways, but there is enough commonality to recognize the original. The same concepts apply to technology. “Next” technology builds on the previous experience and common themes emerge. How am I going to bring this around to Apeiron’s ADS1000 architecture? Here goes:
If you’re old enough to remember the pre-SAN days, you will remember directly attached SCSI devices with dedicated servers running the business. Each critical IT function such as ERP or HRMS had a “siloed” system with dedicated servers directly connected to dedicated storage. It was simple, secure and it worked. Each department could get the job done with this storage and compute architecture. What was the downside?
As manual processes such as paper invoices and timecards went away, data became the most critical asset to the business. The ability to store data for extended periods naturally led to the desire to share the data across departments and geographies. Management wanted to analyze disparate systems and look for trends and opportunities to improve efficiencies. As software such as SAP, PeopleSoft and Oracle Apps became more powerful they needed more compute connectivity. A new way to store, share and scale this critical asset was needed. The age of Storage Area Networking was upon us.
The SAN provided access with authentication, allowing multiple groups within the business to leverage common assets. Specialized software created by the storage companies provided the ability to clone, move and manage the replication of this data for off-line analyses, development and Disaster Recovery purposes. The cost of all this technology? Extremely high across all levels of the organization! Equipment prices sky-rocketed, storage software locked you in, employees to manage the system were much more expensive, etc, etc, etc…As these environments grew, they became something beyond mission critical. Losing critical data can lead to the demise of the company, so the SAN had to become extremely rigid and controlled. Config changes became excruciating, internal customers were not allowed to upgrade their portion of the storage for fear of bringing down other business units, etc…Bottom line is the criticality of the environment made it very painful and cost prohibitive for the Tier 2-3 type applications.
It is at this point we see the trend shift back to something we have seen before, DAS. Departments were drawn to the simplicity and relatively low cost of DAS (defined in this portion as internal server disk). With the advent of larger drives and the ability to install ~2-9 of them in simple 1U server, customers began to defect the SAN for something called scale-out. It was more than adequate for departmental needs, and was a small fraction of the cost. They could loosely couple these commodity servers together for some scalability and redundancy. Frameworks such as Hadoop and applications such as Splunk were born in these environments. They were designed from day-1 to manage internal server storage because the powerful controller available in the Tier-1 SAN was simply not there.
The application had to manage functions such as replication, compression and de-duplication. We once again see a familiar trend; the data started to grow and become mission or business critical. An application such as Splunk is no longer only used for marketing or troubleshooting purposes, it is now considered mission critical as it monitors the entire corporate network for external threats. As these applications proved valuable to the business, they found themselves once again being pushed to the only environment capable of scaling and protecting the data properly; the SAN. However, the software capabilities had grown beyond those early applications. These packages were simply “smarter” when it comes to storage protocols because they were designed to manage DAS. The powerful software capabilities of the FC fabric, and especially the storage controller was simply not required. Add to this the proliferation of NVMe SSD’s and you have some brand-new bottlenecks to getting things done: The storage controller and the external FC fabric.
With AI now able to cull much of the raw data prior to any human interaction, data sets grew exponentially. This growth, coupled with demand for real-time queries simply broke the scale-out model. Installing drives in a server was not adequate to manage and analyze this amount of data. You now have the perfect storm for the next type of storage platform. That is the Apeiron Direct Scale-out Flash system. This system provides all the scale and security of a SAN, but the simplicity of DAS. A 100% native NVMe network with no storage protocol processing to block the performance of NVMe. Switching is integrated directly in to the enclosures with none of the SAN complexity. When drives such as Intel’s Optane are considered, it becomes crystal clear that legacy storage architectures are simply too restrictive to work.
How has Apeiron accomplished this? Like most new concepts in the industry, the architecture builds on past advancements. Apeiron leverages powerful FPGA’s and the NVMe protocol to fundamentally change the way in which data is accessed. Change can be scary, but in this case Apeiron has built an architecture which looks and acts the same way as an internal PCIe connected drive. Apeiron uses Intel FPGA’s on a PCIe connected HBA to encapsulate and move the native NVMe command through a massively scalable network. The I/O is sent directly to the proper NVMe drive(s) and acknowledges that transaction to the application with less than 3 micro-seconds added. With such a low level of network latency, the Apeiron network is invisible to the OS. The scale of SAN with the simplicity of DAS. Exactly how do we do this?
It is typically at this point I start to get the “how do you?????” questions about zoning, security, compression, RAID, etc…To which I answer we don’t do any of that by design. For instance, Apeiron developed the concept of assigning every NVMe drive a unique MAC address. The individual drive (or LUN) becomes a network end-point. This means each application server simply tracks a small number of MAC address versus building and managing unwieldy and latency inducing mapping tables. This replaces the concept of “Zoning” in a SAN. The drives are tied to physical HBA’s ports. What about compression and de-duplication? These concepts were developed to lower the price of very expensive flash. Apeiron eliminates the external switching, storage controllers and software from the storage environment. Coupled with the fact we can leverage drives from any supplier and you have a TCO much lower than traditional storage.
The most critical thing to remember about the elimination of the storage controller and external switches is that the same x86 server will find ~70% more performance! How? The storage controller, drives and switches are the #1 cause of server latency. When these blocking elements are removed, and NVMe drives are added, your server environment will see a massive consolidation (or massive increase in performance).
I’ll be posting some architectural specifics very soon, but you can also visit www.apeirondata.com for videos and whitepapers on our architecture. I hope this helps to bring some context to our developments. As always please reply with any questions at all.