Archive
Solving the Compute and Storage scalability dilemma – #Nutanix, via @josh_odgers
The topic of Compute, Network and STORAGE is a hot topic as I’ve written in blog posts before this one (How to pick virtualization (HW, NW, Storage) solution for your #VDI environment? – #Nutanix, @StevenPoitras) … and still a lot of colleagues and customers are struggling with finding better solutions and architecture.
How can we ensure that we get the same or better performance of our new architecture? How can we scale in a more simple and linear manner? How can we ensure that we don’t have a single point of failure for all of our VM’s etc..? How are others scaling and doing this in a better way?
I’m not a storage expert, but I do know and read that many companies out there are working on finding the optimal solution for Compute and Storage, and how they can get the cost down and be left with a more simple architecture to manage…
This is a topic that most need to address as well now when more and more organisations are starting to build their private clouds, because how are you going to scale it and how can you get closer to the delivery that the big players provide? Gartner even had Software-Defined-Storage (SDS) as the number 2 trend going forward: #Gartner Outlines 10 IT Trends To Watch – via @MichealRoth, #Nutanix, #VMWare
Right now I see Nutanix as the leader here! They rock! Just have a look at this linear scalability:
If you want to learn more how Nutanix can bring great value please contact us at EnvokeIT!
For an intro of Nutanix in 2 minutes have a look at these videos:
Overview:
Organizational Challenges with #VDI – #Citrix
And yet another good blog post by Citrix and Wayne Baker. This is an interesting topic and I must say that the blog posts still goes into a lot of the technical aspects, but there are more “soft” organisational aspects to look into as well like service delivery/governance model and process changes that often are missed. And as Wayne also highlights below and that’s worth mentioning again is the impact on the network that also was covered well in this previous post: #Citrix blog post – Get Up To Speed On #XenDesktop Bandwidth Requirements
Back to the post itself:
One of the biggest challenges I repeatedly come across when working with large customers attempting desktop transformation projects, is the internal structure of the organisation. I don’t mean that the organisation itself is a problem, rather that the project they are attempting spans so many areas of responsibility it can cause significant friction. Many of these customers undertake the projects as a purely technical exercise, but I’m here to tell you it’s also an exercise in organisational change!
One of the things I see most often is a “Desktop” team consisting of all the people who traditionally manage all the end-points, and a totally disparate “Server” team who handle all the server virtualization and back-end work. There’s also the “Networks” team to worry about and often the “Storage” team are in the mix too! Bridging those gaps can be one of the areas where friction begins to show. In my role I tend to be involved across all the teams, and having discussion with all of those people alerts me to where weaknesses may lie in the project. For example the requirements for server virtualization tend to be significantly different to the requirements for desktop virtualization, but when discussing these changes with the server virtualization team, one of the most often asked questions is, “Why would you want to do THAT?!” when pointing out the differing resource allocations for both XenApp and XenDesktop deployments.
Now that’s not to say that all teams are like this and – sweeping generalizations aside – I have worked with some incredibly good ones, but increasingly there are examples where the integration of teams causes massive tension. The only way to overcome this situation is to address the root cause – organizational change. Managing desktops was (and in many places still is) a bit of a black art, combining vast organically grown scripts and software distribution mechanisms into an intricately woven (and difficult to unpick!) tapestry. Managing the server estate has become an exercise in managing workloads and minimising/maximising the hardware allocations to provide the required level of service and reducing the footprint in the datacentre. Two very distinct skill-sets!
The other two teams which tend to get a hard time during these types of projects are the networks and storage teams – this usually manifests itself when discussing streaming technologies and their relative impacts on the network and storage layers. What is often overlooked however is that any of the teams can have a significant impact on the end-user experience – when the helpdesk takes the call from an irate user it’s going to require a good look at all of the areas to decipher where the issue lies. The helpdesk typically handle the call as a regular desktop call and don’t document the call in a way which would help the disparate teams discover the root cause, which only adds to the problem! A poorly performing desktop/application delivery infrastructure can be caused by any one of the interwoven areas, and this towering of teams makes troubleshooting very difficult, as there is always a risk that each team doesn’t have enough visibility of the other areas to provide insight into the problem.
Organizations that do not take a wholesale look at how they are planning to migrate that desktop tapestry into the darkened world of the datacentre are the ones who, as the project trundles on, come to realise that the project will never truly be the amazing place that the sales guy told them it would be. Given the amount of time, money and political will invested in these projects, it is a fundamental issue that organizations need to address.
So what are the next steps? Hopefully everyone will have a comprehensive set of requirements defined which can drive forward a design, something along the lines of:
1) Understand the current desktop estate:
Delivering #Citrix #XenApp on #Hyper-V with PVS and #McAfee – via @TonySanchez_CTX
Good Citrix blog post from Tony Sanchez!
Architectures—whether physical or virtual—should be flexible enough to adapt to different workloads, allowing them to support changing business needs. Although implementing a new IT architecture takes time and careful planning, the process to test and validate an architecture should be easy. In the case of a virtual desktop architecture, test engineers should be able to follow a repeatable pattern, step by step, simply changing out the workload to validate the architecture under different anticipated user densities, application workloads, and configuration assumptions. The procedure should be as easy as learning a new series of dance steps (think PSY’s Gangnam Style, the most watched dance video on YouTube). The point causes me as a test engineer to ask the question: in the case of VDI, why can’t a hypervisor simply learn a new workload just like I might learn a new sequence of dance steps?
Luckily for test engineers, Citrix FlexCast® provides the ability to learn and deliver any workload type by leveraging the power of the Citrix Provisioning Services® (PVS). Recently I worked with engineers from Citrix and Dell, collaborating to build a FlexCast reference architecture for deploying XenApp® and XenDesktop® on Hyper-V on a Dell infrastructure. Testing of this reference architecture looked at how XenApp and XenDesktop performed under various workloads, altering hypervisor configuration settings and examining the overall user experience and user densities. At the drop of dime, FlexCast and PVS enabled a simple switch of the architecture to a new workload.
Based on that reference architecture effort, we recently began a Single Server Scalability (SSS) test using the latest hardware and software releases available. This blog focuses on that effort — what I call the “XenApp dance step for FlexCast style” and how XenApp workloads perform on Hyper-V. (A follow-on blog article will focus on an alternate “dance” sequence for XenDesktop.) The focus of this blog is how the configuration of the McAfee virus scanning software can impact performance and scaling.
In previous blogs, I describe the testing process and methodology that leverages the Login VSI test harness, along with key tips for success. Since those same methods and recommendations apply here, let’s review the configurations we used for this scalability testing as well as the workloads and actual test results.
For background reading, I highly recommend that you review Frank Anderson’s post on XenApp physical versus virtual testing results with Hyper-V. Frank is my colleague and a great resource for insights about testing, including implementation tips and general best practices. In addition, the related Dell and Citrix white paper describing the FlexCast reference architecture for deploying XenApp and XenDesktop on Hyper-V is available here.
Continue reading here!
//Richard
#Ubuntu for phones – backed by #Canonical
I must say that this is really cool and looks great!!
iOS is there as a stable platform that companies can rely on in terms of that SW development on this platform for native apps are great due to that Apple provides both the HW and the SW and therefore simplifies build of apps, you don’t have to make like 150 versions for all the device types out there that you need if you’re developing native apps for Android that uses complex features of the device. I guess the same scenario will come true for Ubuntu unless they only ship it with a small range of devices and keep the focus on true HTML5 apps as long as it fulfills the need…
I wonder how and when Canonical or others will take this Ubuntu platform on and bring it to market on a broad scale…. Anyway it looks very promising!
Read more here and go through the great feature set and design!
//Richard
The IT Melting Pot! 