Microsoft Azure is everywhere?

More and more companies move business critical communication instruments into a cloud based environment. This could be established in a partner datacenter or in a public cloud environment. The main deciding factors between these two options are the trust to the provider and the costs of the solution. Incident and alarm reaction systems like Derdack Enterprise Alert, which adds a highly customizable alarming and service management extension to your infrastructure, are one of the components predestined to be sourced to dedicated Azure Infrastructure. The question however is  how should I plan and size  such infrastructure.

Basic placement and configuration Azure datacenters are available all over the world.  Logicaly the first placement idea is the closest datacenter from the location where the alerts will be created. Mainly to minimize the latency between the event source and the event reaction. But with Microsoft Azure this strategy is not the best in every constellation, because of two placement ideas. First not all necessary services are available in every datacenter and so you need a complete solution architecture including information about VOIP communication, SBC placing, IoT Hubs before you decide. The second point is the connection. All Azure datacenters are connected over the global Azure datalink system. This system connects every Azure datacenter in the world with fibrechannel power and a max latency of 27ms. But this network can only be connected over several connections spots in the world. So based on the local internet provider it could be better to place the Azure infrastructure in a datacenter in Amsterdam or the US East Coast versus doing  it regionally. To verify what works best for you – the ideal testing option is the azurespeed.com latency test.

Once you made the decision on the main datacenter, how you design your solution leads you to the next decision making factor. Several aspects are important in this regard in order for you to reach the best performance of the system.

	Basic infrastructure and availability. This means which type of VMs are required for the infrastructure. The most cost optimizing VM types in Azure are A-Category VMs, but here the ressources are shared. So they  are nice for development and testing but not feasible for productive workloads. Based on the Enterprise Alert requirements a D-Series or E-Series VM is good practice for such an infrastructure. Important to note is that just version 3 VMs should be used, because they offer the best processor and memory proportion. And only use VM types  with SSD support, because you want to reach optimal performance and Enterprise Alert works with a lot of local files and services. A SSD Disk (standart or premium) is an additional must have for the software to perform the best way.   As a recommendation every EA Server on Microsoft Azure should be at least a D2s V3 (2 vCPU 8 GB memory) VM with an E6 managed data disk. The system OS is still a 128 GB managed disk. Don’t use unmanaged disks, because the IOPS and maintenance planning on a storage account is too much. In a redundant system the infrastructure needs two VMs in two datacenters for application availability and per VM you need an update domain and a fault domain. The configuration of three update domains and three fault domains per VM means, that the EA System is replicated on three racks in the Azure datacenter and on three servers over the three racks. This is enough security to protect the EA system from hardware issues and virtualization host updates.
	Monitoring, Anlytics, System Management   Yes, Azure VMs are monitored but they are just monitored from the virtualization system. There simply is not enough information or enough availability testing options in the standard VM monitor of Azure. So if you plan an EA infrastructure on Azure you have to plan for Log Analytics Workspace and an Automation Account.   The Log Analytics Workspace collects the logs of the configured system. It is free up to 5 GB log data per month. In a redundant design with two servers and a database there might be some costs, because in that case Enterprise Alert generates a lot of log data in all respective service compontens. For collecting the log of EA in Log Analytics,  you require custom paths in the log collecting system and the interpreter settings of the log collector must be configured with semicolon separation. Otherwhise the logs of your VOIP Channels can’t be used in the query and analytics reporting.   For automating updates, maintenance and other configurations (could be done over Desired State Configuration) an automation account is required, including a basic config of updates waves and rebooting scenarios. In a redundant infrastructure with the database on an Azure SQL DB there is zero downtime for maintenance and zero time you have to invest for doing maintenance. All that is needed is the testing work done by your customer.   For the backup part a Recovery service vault must be configured for daily backups of the EA server. You have to schedule for one RSV (Recovery Service Vault) per Azure Region.
	Network and Database Services Every Derdack Enterprise Alert system needs a database. Normally the database resides directly on the VM. SQL Express is possible but not recommended by the vendor and on the Azure infrastructure it is my clear recommendation to use an Azure SQL Database. You ask yourself why? If the EA server is a single system on an Azure Subscription there might be little impact, but if you have a redundant system you normally need a SQL server standard or an additional VM. Another reason is, that normally in Azure infrastructures you establish a system of HUB / Spoke VNETs. This means that not all VNETs have access to all other VNETs and because we are planning for an infrastructure in two datacenters or across two regions, there must be a HUB / Spoke design to secure the EA Server and avoid access from outside. Using the Azure SQL Service we have the option to create Endpoints in separated VNets. So it does not matter if the peerings in Hub/Spoke are correct. From the DB service we establish a clear endpoint in every server Vnet and the VM has fast network latency to connect to this database. Another positive point is, that you don’t have to do maintenance and the database can be connected directly over SQL Authentication in a secure tenant environment. The downside is that you have to first create the service and use the EA installer in the advanced mode to establish the connection to the database. To calculate the costs: An Azure SQL Database, calculated in the DTU mode, needs at max a S1 DTU based DB. This means you have up to 20 database transaction units and 250 GB of storage reserved for your database. With this setting the costs are about 25$ per month. No SQL license no connection calls are required. 25$ for a fully encrypted, stored and licensed database is not too much to plan your next infrastructure.
	Additional Services and VOIP integration Based on your requirements there can be a lot of additional components you could use. For example it is not a bad idea to use an Azure load balancer to balance the traffic between individual servers. If you are only using regular load balancing (IP and Port based) you should at least include the traffic manager service. Then every service in the Enterprise Alert system exepting VOIP is web based or has a protocol to stream over HTTP/HTTPS. If there is no active IP and Port based connection from the EA server that requires load balancing you might be better of using Azure Web Application Proxy Service. Why is that? Because in this service you can use the WAP device as your frontdoor and protect the EA server from unwanted direct  web-based communication. This makes for a very safe EA set up and you can benefit from additional options like SSL filtering and individual SSL certificates. Bascially the server and WAP device will communicate with specific system generated certificates whereas public websites have public certificates. This can minimize your costs based on your security requirements.   Tools like IOT Hub, Event HUB or Service Queues can be integrated and directly add to your bespoke VNET. For more details on how to integrate these services, I will write another article.   For some experience sharing on the VOIP side of the house: One of my customers has a really big VOIP scenario. He wants to do everything with VOIP and oncall configuration. Usually VOIP providers don’t want too many lines terminating on one machine and you might see the EA server running low on capacity because so many different SIP and VOIP trunks / connections are required. In this case all you need is a dedicated SBS (Session Boarder Controller). This componet is a dedicated VOIP interface for handling individual SIP trunks. It comes with options like reaction groups, group calls or Teams integration. Nicest point? It can be set up directly in your subscription on Azure. For example the solution from AudioCodes provides you the option to deploy your own SBC close to the EA server, supports your redundancy model and allows you to handle every Oncall-Person Connector as an endpoint (instead of a VOIP service model). This increases your performance significantly. You are planning to use a Skype4Business Server / Lync server for that? Forget it – take your SBC directly onto Azure.

All the above will help you with your basic scoping and project information allowing you to bring your EA infrastructure on Azure. To visualize things a little better for you, I am attaching the below functional diagram / picture of how you can plan your architecture:

Please, have in mind that Azure Services are moving and transforming very fast. In order to make sure that you know every component, their functions and restrictions you have to have a team that works on planning services on Auzre full time. Plus, you require a highly automated framework in your backyard to provide for a highly automated infrastructure. And the monitoring, optimizing and cost optimization needs time and experience, else you will not have the desired results. Just to give you an example, if for your services you plan the wrong disks in the wrong region and you then realise that the IO is not  enough for what you need, you cannot just add more disks for combining more IOPs because you have the wrong Storage Account. So, your EA Server is going to be slow and your reaction time poor.

Another point is the whole area of user management. Microsoft Azure has some restrictions, like that you cannot use an Azure Active Directory as user information center for your LDAP connection. You need e.g. Azure AD DS to provide the interface to the EA server.

“Azure as a Service” MCP (Managed Cloud Plattform) by SmartIT

As a Derdack Partner and active part ot the Derdack community we support other partners, for scoping, deploying and managing EA infrastructures on Azure. Our consulting services can be triggered directly for all Derdack partners. As a Microsft CSP Tier 1 provider we also have the option to directly provide you with subscriptions, tenants and licenses for your customer project, assisting you with providing additional value to your customer’s Enterprise Alert set up.

Choose the easy way to bring our customers the power of Azure with Enterprise Alert!