Issue link: https://cp.revolio.com/i/661564
10 | THE DATA CENTER JOURNAL www.datacenterjournal.com a Data Center is a Data Center is a Data Center F irst, the term data center can be problematic. It's used as a catchall phrase that includes a wide range of facilities. Un- fortunately, lumping any and all data centers together oen leads to the mistaken impression that they are all the same or at least very similar on the inside. Aer all, they are all just rows and rows of racked and stacked servers, right? Nothing could be further from the truth. Each data center is uniquely opti- mized for its intended application. A cloud provider that delivers global knowledge- base searches will optimize for the speed of that search. Its servers will hold data in high-speed memory rather than on hard drives, and its network will be optimized for minimum latency between servers. A cloud provider focused on social network- ing will have a very horizontal distribution of servers, requiring a very flat network infrastructure. Getting information from its le hand to its right hand quickly will be the most important concern. A cloud provider that offers diverse services such as gaming, Internet phone calls, online office applications, cloud storage and so on will have an infrastructure that comprises a bunch of smaller data centers, where each smaller unit is optimized for the individual application. No two data centers are the same, and for this year we can expect to see further optimization of these facilities to reflect their core business. Loose LiPs sink shiPs As anything and everything has "moved to the cloud," so too has confi- dential information that once resided locally on secure media. Bank-account information, credit-card transactions, legal contracts, bookkeeping, tax records, criminal histories—the list goes on and on. Cloud-service providers must maintain security if their customers are to trust their services. Oen, a single security breach leads to more damages in lost business than the breach itself. Back when a data- base could fit in a single room, locking the door was probably enough. But now that the cloud has gone global, with instanta- neous load balancing and local caching all over the world, physical-site security just isn't enough anymore. What's needed is protection as the data is transported from site to site. ere are lots of ways of protecting information in transport, each depending on which network layer is involved. Work- ing from the top to the bottom of the OSI stack, Secure Sockets Layer (SSL) sessions can be initiated at the two ends for higher network layers. At the layer where routers and switches reside, IPSec can encrypt packet flows. At the MAC addressing layer, MACSec is available. Traditionally, MAC- Sec is very limited in use, as it's a point- to-point protocol; that means every node in a network would have to encrypt and decrypt all traffic. is year, however, will see the addition of tunneling to MACSec, thus enabling it to travel anywhere in the world with only the end nodes needing to process the encryption. At the lowest network layer resides optical transport en- cryption. is layer is the most frequently breached, yet oddly it's the least likely to be protected. Encrypting traffic at the trans- port layer is 100% efficient, with no loss of throughput, regardless of packet size. But the higher you go in the network stack, the less efficient encryption becomes. For example, IPSec can have as low as 60% throughput for small packets. So which network layer of encryp- tion is the best for data centers and the cloud they host? Pretty much all of the above. Data center architectures and ac- companying networks are complex enough that each encryption technique can find a home. And for the DCI networks between them, physical-layer encryption is a must. Preventing rain in your CLouD e scale of the cloud has become so immense over recent years that simply managing it has become a challenge. Cloud providers are looking to solve this problem with two techniques that will blossom this year. e first is author- ing bots (soware robots) that run their network for them. Using a combination of iPython routines uploaded to private Git servers, they are able nest multiple layers of automation soware robots that run their network. While the network runs on auto, monitoring soware automatically scans the cloud and puts the status in log files. ese files are themselves subject to moni- toring by soware that flags any problems. But rather than just waiting for a problem to appear, stressor robots also roam the cloud, trying to make failures occur and thus identifying potential problem areas before they become genuine problems. Lost in transLation A second way cloud providers are managing the scale of their networks is open soware. With millions of network nodes from hundreds of vendors, it's simply impossible to have unique soware for each one. Open soware efforts look to generate a common architectural model with a common set of attributes, so that a cloud provider can author a single management tool that controls everything and doesn't require an update every time something new drops into the network. Future data center soware is based on the concept of splitting up the network- management protocol with an associated data-modeling language. For example, SNMP (Simple Network Management Pro- tocol) is the standard Internet protocol for managing devices on IP networks; it uses SMI (Structure of Management Informa- tion) as its data-modeling language. As another example, NETCONF is a network- management protocol based on XML that uses YANG for its data-modeling language. Simple GUIs (graphical user interfaces) and CLIs (command-line interfaces) will not scale to the size of today's global cloud networks, nor do they allow robots to be written to manage themselves.