For this project we partnered with CyrusOne, a leader in top tier mission critical data center facilities. Today they house some of the world’s most influential companies. ianAsher has had the pleasure of working with the CyrusOne team extensively and we are excited to bring access to their amazing facilities to our Houston customers.

We are ready to start taking orders today! For additional information and to request a quote contact sales@ianasher.com.

Designed with high performance in mind this data center can support from 200 to 1,000+ watts per square foot. That kind of power density calls for a robust infrastructure delivering up to 96MW of critical capacity. True 2N power distribution including UPS systems, static transfer switches, banks of 2.25MW diesel generators, and massive on-site fuel storage provide the necessary juice.

Cooling is handled by Stulz 200 refrigeration ton CRAH units and Trane 500 refrigeration ton chillers. The unobstructed 36″ raised floor design forces cold air through the facility. Sensors around the data halls ensure everything is operating at appropriate temperatures.

Security is conducted through layers; From the perimeter gate to the server rack you are constantly filtered from one layer to the next. On-site 24x7x365 security staff man the front desk and patrol the facility. Man traps and revolving doors with biometrics manage access into and around the site. The interior and exterior are under continuous video surveillance and recording. All visitors are logged and accounted for, while a VESDA system and zonal dual action interlocking dry-pipe fire suppression keep staff and facility safe from fire.

When your mission is truly critical compliance matters! This site is designed to meet SSAE 16 SOC I Type II, PCI DSS Sec 9 & 12, HIPAA, ISO 27001, and FISMA standards. Furthermore the facility is also designed to meet TIA-942 requirements for electrical and mechanical systems.

Our team started the build in December of 2018 once hardware landed at the ample facility docks. A totally flat design made carting heavy equipment a breeze across the 640,000 sqft campus to our caged environment. The unique design of the facility features incredibly tall ceilings with a clean room grid. Cable management trays and even power distribution can be mounted to the heavy duty grid with threaded rod. The walls of the cage provide physical protection and increase privacy.

As soon as the PDUs were powered up our engineers were racking and configuring network equipment. Everyone was very eager to get the new environment provisioned, it’s always very exciting to light a new site. Soon we were pinging and ready to start staging customer gear.

Our very talented network SMEs designed the network architecture and infrastructure. The goal is to ensure high performance, resiliency and redundancy at all layers. Our network features a mix of four carriers, redundant core switches, redundant firewalls, and ability to hand off redundant active-active 10Gbps networking straight to our customer’s racks.

Remember to contact us via our form or reach out to sales@ianasher.com for more information!

Our team held a bracket competition and had a final match between the top players. Ultimately Mannon Stewart took home first place as the overall bracket winner.

Ansible is a terrific way to maintain configurations across large scale deployments. It is favored by many devops teams and comes in both open source and commercial flavors from Red Hat. For more information about these work shops please visit the Ansible website.

What I wanted to discuss today was the fundamentals of good network design. There is a saying that designing a complicated network is simple but designing a simple network is complicated.

It has been my observation that a strong design discipline as well as lacking documentation skills are the biggest downfall of IT staffs in general. Documentation is often a fundamental problem of motivation and priority but there are certainly documentation skills that can help.

But first we want to consider what a network is fundamentally? Is it a collection of links, protocols and devices that move packets? No, it is not. Fundamentally, it is a mechanism or an infrastructure, built to carry application traffic that enables a business or entity to function. We must have the proper perspective when coming into a network design situation to begin with. At the end of the day, in an enterprise or service provider scenario, we need to “enable the business”. Fundamentally, the network should enable application communication in a reliable and predictable way, with as little overhead and oversight as possible.

What this means: the FIRST step to designing a network is to think about and define the PURPOSE of the network. (Requirements, baseline, etc.)

That’s no network… it’s a system for application enablement!

Next to consider are the fundamental network requirements. Generally, the first major consideration is to reliably enable the business to achieve its goals, thus the network must be reliable.

Determining the level of reliability necessary is the next logical step in the design process. What constitutes a failure? Can the business, or certain aspects of the business, survive a short term outage? Are there business resiliency protocols built in to protect against general technology failure or is the business or an aspect of the business totally dependent on technology availability? Again, thinking in terms of the network as an infrastructure built to carry application traffic that enables the business, one should begin to define the applications and their level of criticality to the business. We will not delve into too many details but as a general example, in most enterprises a short email outage may result in only discomfort, in other businesses it may be more critical. On the other hand, in high frequency trading applications, a relatively short change in the network that disrupts even the consistency of the network can be extremely damaging. In this instance, zero packet drops with a minor increase in network jitter can constitute a network failure.

In building a reliable network, it is important to understand that there is a difference between resiliency, reliability and redundancy. Redundancy is a mechanism that MAY achieve a measure of resiliency but resiliency may not require redundancy and redundancy may not equate to resiliency. On the other hand, increasing resiliency by adding redundancy doesn’t necessarily increase reliability. For example, if a high speed multi-hop link is used to backup a high speed direct link, the additional latency and jitter introduced by the backup link may cause applications to perform poorly or even to fail. In such an instance the network has essentially failed to enable the applications. The network has failed to provide reliability.

Note: a good rule of thumb, where resiliency is critical, is that removing single points of failure by adding two way redundancy is relatively efficient. Trying to remove dual points of failure often comes with greatly diminishing returns that must be weighed carefully.

What this means: the SECOND step is to design a reliable network by considering what constitutes a ‘network failure’ from the standpoint of the applications.

What that in mind, we move to the next major tenant of designing networks: manageability. It is inevitable that networks will experience change over time. Building a manageable network is often an exercise in simplicity. A simple test to determine if a network is manageable is the “2am test”. Consider that it is Friday night and you are awoken by a phone call due to a network failure. You are called upon to troubleshoot a segment of the network that you have not touched in over 3 years. Bleary eyed and exhausted you log into a network management console and review the current configuration of the devices in question. Will you be able to clearly and easily understand the relationship between the route advertisements, route-filters, ACLs, route-maps, QoS and traffic engineering? How much time will be necessary to decipher the original intent of the configuration and how it may have been modified over the years? Five minutes, fifteen minutes, 2 hours? All precious time when trying to enable the magical reliable “five nines” network.

Beyond the complexity of the network is the concept of documentation. As stated at the onset, the two primary failings in IT organizations that I see today are design discipline and documentation skills. A manageable network is one that is easy to understand. Good documentation is critical to being able to quickly learn and troubleshoot a network. We will not extensively cover network documentation in this blog post but there are numerous sources of good information that can help you but suffice it to say that generating a network baseline (utilization, availability, etc) and good topology, addressing and application flow diagrams are at the core of good documentation. Consider the “2am test” and the effects of a well documented network vs a poorly documented network on the results.

What this means: the THIRD step is designing a manageable network. Take the “2am test” and see how you can reduce the learning curve through simplification and documentation.

The last major consideration when beginning the design process is to consider how the business or organization may change or grow as time progresses. The goal of any business is growth. The network should be ready to grow with both technology and business. Scaleability is not just related to the ability to grow nor is it necessarily predicated on the size of the network. A small network may be unstable and require major rework to adapt to new applications whereas a large network may be very stable and require little change to adapt to new application requirements or technologies.

There is a fine balance between reliability, scaleability and manageability. These are the primary goals a good network designer should aspire to achieve.

Generally, the more manageable the network the more scaleable it becomes. Conversely, adding reliability mechanisms like redundancy can decrease scale and manageability in a linear fashion. Consider, that in order to remove any single point of failure a full redundancy of all systems doubles the system in all aspects. In order to remove double points of failure it is often necessary to add a third layer of redundancy  The increase in convergence time, management overhead and scaling limitations may or may not outweigh the benefits of resiliency in these scenarios. Adding further redundancy may likely be a net loss to the resiliency of the system.

What this means: the FOURTH step is designing a scaleable network by carefully weighing the relationships between redundancy and resiliency in relation to what constitutes reliability of application performance.

In summary: Fundamental to designing a network is the fine balance of the reliability, scalability and manageability of the system for the purpose of enabling applications that allow a business or entity to function.

Personally, I am a big fan of the KISS (Keep It Simple Stupid) principal. Simplicity in network design is key but just as important is the second S in KISS … stupid. The more you learn the more you know what you don’t know. Since attaining my CCIE just over a year ago I have learned more and more just how clueless I really am. I think it is equally important for us to be humble in admitting that we really are ‘stupid’ in relation to the vast volumes of information available for us to consume. With that in mind I leave you with this well known quote:

“NEVER MEMORIZE SOMETHING THAT YOU CAN LOOK UP.”

― Albert Einstein

NOTE: This blog post was inspired by my musings and study of the book: Optimal Routing Design by Russ White, Alvaro Retana and Don Slice. This blog post is essentially a very quick summary of the basic tenants of the book with a little bit of my real world experience sprinkled in.

http://www.ciscopress.com/store/optimal-routing-design-9781587051876

http://packetpushers.net/author/rwhite/

If you are attending the event and want to reach out, please fill out our contact form.