Exhcange related stuff
The latest buzzword in virtualization, yet for me the technology it describes is old hat (in the I.T. world old hat isn’t all that long ago). Let me explain…traditionally a ‘converged’ system is simply a combination of 2 (or more) great bits of technology with very different roles combined into one. An example of a converged system is VCE, where I still think of it as the ‘V’Mware, ‘C’isco and ‘E’MC alliance:
- VMware – provides the virtualization function
- Cisco – provides the network and server layer (with a little help from Intel!)
- EMC – experts in storage, so you can guess what they provide!
[With Intels contribution it should really be called ‘ViCE’ 😉 ]
Together that means a joined up system, a VBlock, that you simply deploy then use as a converged compute system. Want more performance? Then add more CPU or RAM or Storage…
…and that is where Hypercovergence differs. Instead of isolated blocks of converged compute you have ‘blocks’ that can work together and scale out, want more performance? Add another block to an existing one via a network cable and BOOM! You have more power. Add 10 blocks. Or 50!
Why did I say it was ‘old hat’ I hear you ask? Well, that’s exactly the way MongoDB works, it scales out in pretty much the same way. When your databases reach a certain size and you need more oooomph, traditionally you would need to migrate the workload to a beefier machine. What if there was a better way, one perhaps that could make use of some of the spare CPU cycles available in an existing machine or one that allowed a redundant piece of kit become useful again? I’ll explain with pictures:
Poor chap, a lowly P75 system crunching away at that data. Need to urgently number crunch the number of stars in the universe and the probability % of habitable planets? Well you need more ooooomph, so scale out like thus which MongoDB has been doing for years (since 2007 while VMwares bitter rival Nutanix first released their Virtual Compute Platform in Q4 2011) :
OH look at that, my Xeon buddies have joined in the game. Now with all that Quad core Hyperthreading with a bit of clever sharding on the MongoDB config you’ll be finished calculating in no time.
So that’s what Hyperconvergence is pretty much. The ability to add more by simply using Ethernet. No need for messy transitions or complicated integration paths and reams of consulting days. Buy it, plug it in, switch it on, use it.
Of course Hyperconvergence is a little more than my simplistic analogy, it’s changing the landscape for virtualization and storage. Previously you would need to integrate 4 or 5 vendor offerings to get your virtual compute platform running. Now you don’t have to. Buy just one (very expensive) hyperconverged box and spin up 100’s of workload VMs to do your grunt work. Potentially you can reduce significantly the number of racks of servers you have, and power/storage costs anywhere between 20 to 80%. Impressive stuff
The following are ones to watch:
Nutanix – possibly more famous for rowing with VMware
SimpliVity – simple isn’t it! Get a free ‘For Dummies’ book here
PernixData – just like The Flash, these guys are fast
I wonder what NetApp are thinking right now…?
Probably enjoying the ever growing spat between VMware and Nutanix, my buddy Chuck started it all with this > 10 reasons why vmware is leading hyperconvergence
The question is often asked if Shared Mailboxes can be put into a 2 way continuous synchronisation throughout the duration of migration to allow both migrated & non-migrated users access to the same Shared mailbox with the same content and to be able to function from both systems at the same time.
This is not possible using the Quest/Dell Software toolset for mailbox synchronisation and migration. There can only be one ‘live’ instance of a Shared Mailbox, either on the legacy or the target messaging system. Not both, Not ever.
The recommended approach from Quest/Dell Software is to migrate Shared Mailboxes together with the user mailbox migrations. The preferred approach is to switch the Shared Mailbox at the same time as the key users of the shared mailbox, else leave it in legacy until the last user is across to the target platform.
If using the Sync & Switch method for Shared Mailboxes the following will apply:
Shared Mailbox still live on Legacy Platform
Legacy Users continue to have access exactly as today
Target Messaging service users can see the target copy of the Shared Mailbox (Outlook 2010/2013 automatically add in all Shared Mailbox a user has permissions too – whether migrated or not), users can:
- Read items & Reply from the Shared Mailbox
- The Read status & Replies will NOT synchronise back to the live Shared Mailbox in legacy
- New email items will only appear during the next synchronisation pass (which could be a delay of minutes to hours)
In this situation end users already switched to the Target Messaging system often mistakenly think that the Shared Mailbox is fully functional as they can see it and may see new items periodically updating.
Shared Mailbox switched to and now live on Target Platform
Legacy Users will still have access to the legacy Shared Mailbox contents as they were prior to the switch, however no new emails will appear and they will be unable to reply to old email (they will only be able to forward email internally). All new email will have been re-directed to the target Shared Mailbox as part of the mailbox switch
Target Users have access to the migrated target Shared Mailbox exactly as they did in legacy but now with all the full functionality. Users will be able:
- Read and Reply to all emails, both internal and external
- Organise folders as needed
- New emails will appear immediately in the Inbox, bypassing the legacy Shared Mailbox
If using the Remote Collection method for migration any Shared Mailbox content can only be live and valid on either the source or target messaging system, not both, which means the target Shared Mailbox will be empty until the Remote Collection migration is triggered. Once that is triggered the legacy Shared Mailbox is no longer useful as it loses functionality.
Real advice, Real Experience
I often make a judgement call on switching Shared mailboxes, I advise customers to switch them once the key users who need access to it are switched. You can use Quest/Dell Software Reporter or a PowerShell script to list out all Shared Mailboxes and who has rights to them. It is then a case of identifying and contacting Shared Mailbox owners and agreeing a plan of action. Communication is important here, set the expectations clearly and you will have a smoother ride. Don’t second guess when it should be switched.
Always in a state of transition, IT departments around the world are continually deploying new systems, applications and hardware. However one of the biggest changes, and challenges, is the successful migration from an existing infrastructure to a whole shiny new one with all the bells and whistles it comes with.
Let me quickly introduce myself, I’m Zulf and I currently work for Fujitsu as a Solution/Technical Architect mostly on migrations with a particular focus on Active Directory, Exchange and SharePoint.
Preparation, preparation, preparation! That there is my mantra, the first word that comes out of me when looking at any migration. It really doesn’t matter whether the migration is large or small, preparation is key and I’ll tell you why.
Without it you will undoubtedly fail, or if you to manage to somehow struggle through, the stress and strains upon the shoulders of those tasked with the migration will lead them to breaking point. I can truly say I have “been there, done that”, I worked on one of the biggest migrations in the UK – 125,000 seats over a 30 month period – yet the migration of the data (filestore and email) was treated as a minor irritation by the project planners as it was deemed straightforward – copy and paste anyone?
The result? An inefficient, trouble strewn, terrible state of affairs that ended up using more resources than it needed, took twice as long as it should and resulting in levels of stress and anger never before seen in the user environment. The ‘planning’ time set aside for this monumentous migration task (which spanned the whole UK) was a truly dismal 6 weeks.
The fix? Prepare! It is actually quite simple, follow my easily digestible non-technical guide to running a technical migration. Here goes:
Understand what you want to do: What are you trying to achieve? What are your outcomes, timeframe and budget. Your timeframe? Double it now!
Understand how you are going to do it: Identify the tools, resources, expertise and finances needed to effect your change.
Prepare: Lay the groundwork, communicate with the affected parties and create a plan of action in your chosen project methodology. Be realistic with your timelines.
Prepare again: Purchase the products and tools you need, book in the resources and ensure the right equipment and tools are available and accessible.
Prepare once more: Prepare for the unknown. Yes, that’s right – prepare for something you’re not even aware of yet. How? Purposely set aside delays in your project (catch-up days, firebreaks) for the infamous Rumsfeld ‘unknown unknowns’ – use them if you need them, finish up early if you don’t.
Pilot: Once you’ve got what you need find a sample (whether it is users, computers, servers etc. etc.) and run through a mini version of your end to end migration. Yup, the whole thing from start to finish – in some cases you may not be able to go the whole way, but if that means you have to pilot a further change at a later time DO SO!
Deploy & Migrate: Finally that point when you can approach a migration with confidence
If you are indeed planning or going through a migration and need assistance get in touch with me here at my Blog and you can be assured that a friendly and experienced consultant (me!) will respond.
Too often an organisation changes only when forced to, either by policy, necessity (end of life, end of support) or organisational change. It is always best to change when you have the control, so be proactive, look at what’s coming over the horizon and act quickly.