The main concept with the new disaster recovery option on CS 14 is the ability to separate the SIP registrar allowing for a primary and secondary registrar. This concept has been talked about somewhat with survivable branch appliance with an Enterprise Pool but it is also an option with dual Standard Edition servers.
When Communicator 14 registers it receives the primary and secondary register in-band in the SIP signaling along with other information about meeting policy’s etc. Although there has been some mention of SRV DNS records it is defined in topology builder (another blog post for another time)as the backup registrar pool and passed via in-band signaling to the client when logging on to Communication Server.
This feature is really about keeping voice up and available in the case of a data center failure. Although I have showen the concept of two remotely located datacenters this doesn’t have to be the case. In the case of a small enterprise this could be the same rack for all practical purposes in the case of wanting to provide some hardware resiliency to voice.
Features during DR:
What’s great about this solution is its simplistic nature. No load balancing required. It also provides the ability to continue doing peer to peer sessions for datasharing, IM and video. When in failover mode the user receives a clear indication that there is an issue and to expect limited services. A big red banner is displayed across the client until services are restored. If you want to restore full services quickly to your users you can migrate your users on to the still operational SE server and they will be back up and working with full UC features.
As you can see I have also placed the mediation server functionality on the SE server so with the addition of two gateways you have a full UC solution of 5000 users with five 9’s for voice with two servers. Now of course if you want to add additional functionality like remote VPNless access to Communicator you will need additional servers but even with every service and role deployed your server count will remain relatively low. This also doesn’t account for virtualization which is still to be announced.
This scenario is great for up to 5000 users. Even though each server is capable of housing 5000 users on its own placing 5000 users on each server would mean that in a DR scenario that 10,000 users would be registered to one server which may not be supported. My thought here is what if you wanted to migrate the users from the failed server over to the still functioning server you would need spare capacity. Of course in a larger environment you could have an SE server actually fail over to a fully blown Enterprise pool so scaling to a much larger deployment in the future is also an option.
In summary, this is a great option for small business looking to expand its UC capabilities. It simplifies the deployment while improving uptime. It is also an option for the larger enterprise trying to provide some local hardware resiliency for a large remote site where an SE server can fail back to a pool or over to another SE server. The beauty in all this is flexibility to build the UC deployment that meets the needs of the business.
Comments welcomed.
VoIPNorm
thanks!
ReplyDelete