irq
February 2010
Arista, Blade win top spot in data center switch test →
networkworld.com
“This test analyzes switches, each sporting at least 24 10Gigabit interfaces, from Arista Networks, Blade Network Technologies, Cisco, Dell, Extreme and HP. We compared these products 10 different ways and subjected them to three months of grueling performance tests.”
“Cut-through designs typically deliver lower latency, but there are tradeoffs. The biggest issue is that cut-through switches will forward corrupted frames, since they don’t wait to see if the checksum at the end of each frame is valid. A router or other store-and-forward device will keep corrupted frames from leaving the data center, but such traffic could be a problem inside the data center, especially in large broadcast domains.”
—Latency and jitter: Cut-through design pays off for Arista, Blade
“The “danger” with compression algorithms is two-fold. First, applying compression without consideration for the network link and the type of data can actually degrade performance by increasing response times. This is because in some situations it takes longer to apply the compression algorithm to the data than it would to transfer the raw data across the given link. Second, the location within the network where compression is applied can have a deleterious effect on other infrastructure components attempting to act on the data, because it must decompress the data, apply its policies, and then recompress the data. This is similar to the problem of end-to-end SSL encryption of data, which forces intermediaries either to abandon their function (a bad idea) or to decrypt, execute, then re-encrypt data.”
—
WILS: The Many Faces of Compression
WILS: The Many Faces of Compression
“Network time represents how long a user is waiting while data is transmitted between their computer and Facebook. We can’t completely control network time since some users are on slower connections than others, but we can reduce the number of bytes required to load a page; fewer bytes means less network time. The 5 main contributors to network time are bytes of cookies, HTML, CSS, JavaScript, and images. Generation time captures how long it takes from when our webserver receives a request from the user to the time it sends back a response. This metric measures the efficiency of our code itself and also our webserver, caching, database, and network hardware. Reducing generation time is totally under our control and is accomplished through cleaner, faster code and constantly improving our backend architectures. Render time measures how much time the user’s web browser needs to process a response from Facebook and display the resultant web page. Like network time, we are somewhat constrained here by the performance and behavior of the various browsers but much is still under our control. The less we send back to the user, the faster the browser can display results, so minimizing bytes of HTML, CSS, JavaScript, and images also helps with render time. Another simple way to reduce render time is to execute as little JavaScript as possible before showing the page to the user. The three metrics I describe are effective at capturing individual components of user perceived performance, but we wanted to roll them up into one number that would give us a high level sense of how fast the site is. We call this metric Time-to-Interact (TTI for short), and it is our best sense of how long the user has to wait for the important contents of a page to become visible and usable. On our homepage, for example, TTI measures the time it takes for the newsfeed to become visible.”
—Facebook | Making Facebook 2x Faster
“What is needed is to re-architect the way traffic should flow, so that it makes better use of all the available paths. This requires the building of larger, physical/logical networks (think flatter) to account for applications such as Virtual Machine (VM) mobility across interconnected hosts within a single network. Brocade is working with the Internet Engineering Task Force (IETF) on a standard called Transparent Interconnection of Lots of Links (TRILL), which provides multiple paths via load splitting. TRILL will allow us to reclaim network bandwidth and improve utilization by establishing the shortest path through Layer 2 networks and spreading traffic more evenly. The net effect is that the network can respond faster to failures. By addressing the limitations that STP poses, the data center network will be able to scale to meet the demands of virtualized and cloud computing environments with on-demand Layer 2 network capacity.”
—
Brocade gets behind TRILL.
How Much Are Cloud Providers Making? « Data Center Knowledge →
datacenterknowledge.com
“How much are the major players in cloud computing making from their cloud operations? The answers are all over the map.”
The to and fro: Acting like a friendly, fun consumer service provider when you offer boring internal enterprise IT services →
thetoandfro.com
I’m an IT Director of an internal, enterprise IT organization.
But more and more I find myself influenced and inspired by people and industries outside of my profession.
One thing I talk about with my staff a lot is offering customer-centric services. Some people call this: the…
“
Third-party systems integrators, value-added resellers (VARs) and consultants is another constituency threatened by the single-vendor data center. These channel players make their money by tying together equipment and software from different vendors to best suit a customer’s needs. Sometimes they act as outsourced IT shops and these VARs are watching the converged infrastructure play with much interest and are already feeling the repercussions of growing tensions between erstwhile partners Cisco and HP.
One New England VAR executive said that in the past his company successfully sold solutions including HP servers and Cisco routers and EMC storage into many accounts, with the support of all vendors. Now, he gets pressure from each vendor — especially HP — to offer a one-vendor solution, and that support has waned.
” —IT shops want more throats to choke
To L2 or not to L2, that is the Question for VMotion →
blogs.cisco.com
“This is a favorite question of mine (and a very contemporary topic), albeit asked in a different way; Why do you need layer 2 for VMotion. Those bearing the email signature of VCP, will be quick to show off their shiny new badge and tell you it is because of VMotion, because of a port group label, or some other VMware specific component. In fact, there is a more fundamental reason. It is called an ARP cache, IP Address, Default Gateway and DNS.”
Looking at the Cisco Nexus 1000v for your VMware environment? Some considerations…. « Jason Nash’s Blog →
jasonnash.wordpress.com
“We’re starting to see a serious uptake in interest in deploying the Nexus 1000v virtual distributed switch. I believe the latest service release calmed some fears about this new product and having some references to point at always helps. As we perform more implementations we’re starting to see some things that customers need to be aware of in the planning stages. To put it simply, the standard vSwitch network architecture lets you do some things that the Nexus 1000v won’t, and that’s normally a good thing. It stops a lot of bad habits that will get you in to trouble later. So in no particular order or train of thought…here you go!”
“NYC Seed funds seed-stage technology entrepreneurs in New York City. We help driven, small teams move from an idea to a product. Through the combined efforts of New York City’s most innovative organizations, NYC Seed provides funding, mentoring and support to create the next generation of companies in New York City.”
—NYC Seed
first thoughts on otv
Ok, over a dozen requests for something on Cisco OTV breaks the threshold.
Randomly:
- OTV is standard Cisco: a pragmatic and fast response to an emerging need or requirement (depending on who you ask).
- It’s not sui generis. There’re other ways to achieve the same basic functionality that have been around for some time: MPLS, VPLS, EoMPLS, L2VPNs, Pseudowires, PLSB/SPBM, EoDWDM, plain ol’ Metro E, blah blah blah. All of these services allow L2 continuity across data centers with various architectures and capabilities for scale, management, automation, spanning-tree suppression, etc.
- Looks like decent design.
- Like with anything, there’ll undoubtedly be scale, performance, etc., limitations to start, that will be improved over time.
- Note that they don’t say the devices running OTV have to be in any particular data center network layer. Interesting, that.
- The supposed ease with which it can be set up, maintained, and managed is a differentiator.
- The fact that it’s WAN transport agnostic, as long as whatever it is can carry IP, is another.
- The whole transport over IP thing is a huge architectural decision, imo. It’s a strong hint to Cisco’s strategy re multi-site connectivity, L2 continuity, the interclouds, etc.
- It’s not a panacea. Nothing ever is. Get over it.
What do you think?
a word about what can be said
I’m often asked to comment on particular vendor offerings, technology roadmaps, etc. What I can say is governed by: corporate policies, NDAs, etc.
What I try to do is be generic and give my view insofar as it does not point to specific bits of information I don’t publicly have. But it ain’t easy.
“
The underlying table information and routing transport for this scenario is a pretty neat adaption of existing technology. Cisco is leveraging some of the capabilities of the IS-IS (Intermediate System to Intermediate System) routing protocol to make this happen, although the IS-IS configuration is completely under the covers. It really is only about five commands to add a data center to the mix, although the necessary configuration of the Nexus 7000 switches might be a bit more involved.
The upshot is that even though the overlay transport is transparent to the ends of the connection, there’s no fear of spanning-tree looping as each site maintains a distinct spanning-tree topology and BPDUs aren’t forwarded across the WAN. The OVF functions as a gatekeeper for the frames that should remain local while forwarding those that should be allowed to pass.
When databases fly In the demo I saw, Cisco used OTV to migrate a loaded SQL Server VM from one VMware ESX host to another over a simulated WAN, with the hosts residing at different data centers the equivalent of 400km apart (4ms latency). The VM migrated over in about 30 seconds or so without losing the connection with the client load… with one catch. Although the VM definitely moved, the virtual disk didn’t. (Moving an 8GB VMDK through an OC-12 would take far longer than 30 seconds, and such a trip isn’t really feasible for a VM under load anyway.) In the demo, Network Appliance’s FlexCache technology bridged this gap, enabling the VM disk to remain in the original data center while keeping the delta at the new data center. Naturally, this isn’t a scenario that lends itself to a permanent migration, but it might prove useful in some load-balancing and global distribution scenarios.
It’s important to note that the established connections to migrated VMs continue along their original data paths. Even though the VM ends up running at the remote data center, the existing TCP connections to that server must still pass through the initial data center to maintain the consistency of the connection. New connections could be rerouted to the remote data center, but an existing connection cannot. This could add significant latency and bandwidth consumption to the WAN links if not monitored. It should also be noted that current technologies put a distance damper on any effort like OTV, since VMotions on links with greater than 4ms latency can get problematic really fast. This roughly translates to 400km of physical separation. This isn’t a limitation of OTV, but it’s still a constraint.
” —First glimpse: Cisco OTV