New and old technology usually don’t work well together. Trying to connect your Betamax video player to an OLED screen may be a challenge. It will work, but how? The same principle applies to traditional firewall setups in the cloud. With the virtualization of the networking stack not all features available in physical networks are […]
Basis of SLA’s An SLA is an agreement on service availability, performance and responsiveness. In this paper, only the availability SLA part is addressed. When indicating SLA’s however in this document, we are talking about the Minimum time a service or component needs to be available, or the maximum time allowed to be down. When […]
Pretty quietly Azure has released the option of using redundant VPN connections. In this case, the gateway in Azure actually gets 2 external IP addresses that our on-premises Firewall can connect to. In this chapter, a small update on the Juniper SRX, BGP to Azure post. So that after following this guide, you can actually […]
Ever since playing with BGP I was looking for a way to make redundant tunnels. As the local internet provider here would only allow me a single IP address, I looked at the other side. What if we have two Azure regions that have a VPN tunnel to my SRX and between each other. Routing would be dealt with by BGP and thus, I should be able to connect to both VNET’s through each of the VPN tunnels.
Many companies struggle with concepts of “cloud networks” and how it relates to their on-premises networks. How do you deploy a firewall in there, with multiple subnets? Do we need multiple VNET’s and what about those subnets? Well, this post is about what you actually need to understand prior to deploying 3rd party firewalls (and/or VNets) and how routing works inside a VNET, and finally the common mistake of comparing an Azure VNET to a Hyper-V/VMWare VNET.
Geo Clustering exists in many options, and dependent highly on the requirements and technical capability. This post is to discuss some options and things to consider before deploying any geo-cluster.
Data GEO- Redundancy
The first dependency in clustering is storage capability. Data from the workload in the cluster will be written to disk and that data needs to be available on both sites. Within Microsoft SQL AlwaysOn can replicate the data for the instances and ensure it is available on both sites. It is also possible to have the storage perform data mirroring.
When sending data from site A to site B, two options exist: Synchronous and A-Synchronous.
Synchronous: Data is written to BOTH sites before the application or server receives a successful write notification
A-Synchonous: Data is written to the primary site, the application or server receives the write, and THEN the data is written to the second site.
Within a synchronous architecture, there is very limited chance of data-loss upon a failure, as the application knows the data is written in two locations. With A-synchronous data loss can occur.
While synchronous looks most tempting, it requires fast connections between the storage / servers in order to reduce latency for every I/O write action. Therefore this is not always possible and a-synchronous is the only option left.
Storage mirroring or AlwaysOn data replication must be used to provide data geo-redundancy