Much of the rote knowledge of the IT field, especially that of the SMB field, arose in the very late 1990s based on a variety of factors. \u00a0The biggest factors were that suddenly smaller and smaller businesses were rushing to computerize, Microsoft had gotten Windows NT 4 so stable that there was a standard base for all SMB IT to center around, the Internet era had finally taken hold and Microsoft introduce their certification and training programs that reshaped knowledge dissemination in the industry. \u00a0Put together, this created both a need for new training and best practices and caused a massive burst of new thinking, writing, documentation, training, best practices, rules of thumb, etc.<\/p>\n
For a few years nearly the entire field was trained on the same small knowledge set and many rules of thumb became de facto standards and much of the knowledge of the time was learned by rote and passed on mentor to intern in a cycle that moved much of the technical knowledge of 1998 into the unquestioned, set-in-stone processes of 2012. \u00a0At the time this was effective because the practices were relevant but that was fifteen years ago, technology, economics, use cases and knowledge have changed significantly since that time.<\/p>\n
One of the best examples of this was the famous Microsoft SQL Server recommendation of RAID 1 for the operating system, RAID 5 for the database files and another RAID 1 for the logs. \u00a0This setup has endured for nearly the entire life of the product and was so well promoted that it has spread into almost all aspects of server design in the SMB space. \u00a0The use of RAID 1 for the operating system and RAID 5 for data is so pervasive that it is often simply assumed without any consideration as to why this was recommended at the time.<\/p>\n
Let’s investigate the history and see why R1\/5\/1 was good in 1998 and why it should not exist today. \u00a0Keep some perspective in mind, the gap between when these recommendations first came out (as early as 1995) compared to today is immense. \u00a0Go back, mentally, to 1995 and think about the equivalent gap at the time. \u00a0That would have been like using recommendations in the early Internet age based on home computing needs for the first round of Apple ][ owners! \u00a0The 8bit home computer era was just barely getting started in 1978. \u00a0Commodore was still two years away from releasing their first home computer (the VIC=20) and would go through the entire Commodore and Commodore Amiga eras and go bankrupt and vanish all before 1995. \u00a0The Apple ][+ was still a year away. \u00a0People were just about to start using analogue cassette drives as storage. \u00a0COBOL and Fortran were the only series business languages in use. \u00a0Basically, the gap is incredible. \u00a0Things change.<\/p>\n
First, we need to look at the factors that existed in the late 1990s that created the need for our historic setup.<\/p>\n
In the nearly two decades since the original recommendations were released, all of these factors have changed. \u00a0In some cases the changes are cascading ones where the move from general use RAID 5 to general use RAID 10 has then causes what would have been the two common array types, RAID 1 and RAID 10, to share access\u00a0characteristics\u00a0so the need or desire to use one or the other depending on load type is gone.<\/p>\n
These factors highlight why the split array system of 1995 made perfect sense at the time and why it does not make sense today. \u00a0OBR10, today’s standard, was unavailable at the time and cost prohibitive. \u00a0RAID 5 was relatively safe in 1995, but not today. \u00a0Nearly every factor involved in the decision process has changed dramatically in the last seventeen years and is going to continue to change as SSD becomes more common along with auto-tiering, even larger caches and pure SSD storage systems.<\/p>\n
The change in storage design over the last two decades also highlights the dangers that IT faces as a large portion of the field learns, as is common in engineering, basic “rules of thumb” or “best practices” without necessarily understanding the underlying principles that drive those decisions making it difficult to know when not to apply those best practices or, even more importantly, when to recognize that the rule no longer applies. \u00a0Unlike traditional mechanical or civil engineering where new advances and significant factor changes may occur once or possibly never over the course of a career, IT still changes fast enough that complete “rethinks” of basic rules of thumb are required several times through a career. \u00a0Maybe not annually, but once per decade or more is almost always necessary.<\/p>\n
The current move from uniprocessing to multithreaded architectures is another similar, significant change requiring the IT field to completely change how system design is handled.<\/p>\n","protected":false},"excerpt":{"rendered":"
Much of the rote knowledge of the IT field, especially that of the SMB field, arose in the very late 1990s based on a variety of factors. \u00a0The biggest factors were that suddenly smaller and smaller businesses were rushing to computerize, Microsoft had gotten Windows NT 4 so stable that there was a standard base … Continue reading The History of Array Splitting<\/span>