As per the Traffic Manager FAQs in the unlikely event of an outage of an entire Azure region, Traffic Manager is expected to continue to function normally.
Can someone please confirm if during an Azure worldwide outage, Azure Traffic Manager is expected to function normally or not?
Traffic manager is not a regional deployment. It is a service which spans across data centers. In case of any regional outages, your Traffic manager still continues to work but the endpoint which you have added might fail as it is a regional deployment.
Related
This is Yaseen Zafar. DevOps Engineer from Integrated Dealer Systems. We have multiple customers whose servers are hosted on multiple locations from Canada to America. They are hosted on premises (i.e. they are not currently on Azure). Though we are currently using Microsoft Azure Log Analytics to get some insights of the Windows and Linux Servers. So far it has been a very good experience.
Actually I wanted to know if there is any solution available on Azure that can show me firewall related logs, rules, IP and port details ingested from the Windows and Linux Servers that are hosted on premise location.
Best Regards.
Yaseen Zafar
• Yes, there is a way through which you can forward your on-premises firewall logs to Azure log analytics workspace since almost every firewall device has syslog functionality in built in it to forward logs to a log management server on a specific port. Thus, similarly, on-premises firewall logs that include all data collected related to the traffic passed inbound and outbound to the environment can be forwarded to a Linux virtual machine which then can be forwarded to the Azure Log Analytics.
• Syslog is the cross-platform equivalent of Windows Event log which can be leveraged by forwarding these syslog messages to Azure Log Analytics through Linux machines. This linux system should be deployed as a virtual appliance (VM) in on-premises or in Azure cloud such that the syslog-generating firewalls can communicate directly with them. The Linux forwarder can be on-premises physically near the firewall, or it can be in Azure or another cloud, connected to your firewall by an IPSEC tunnel. The Linux computer has a Log Analytics agent configured to communicate with your Log Analytics workspace.
• Once your firewall is connected to Azure Log Analytics you should create a custom dashboard solution that suits your needs. You will have excellent visibility and gain a lot of insight into your firewall operation by studying the collected and indexed syslog data in the Log search feature of the Azure portal. You will notice which types of data your firewall is delivering and learn what to monitor to meet your business and security needs.
Please find the below links for more information on how to configure the Linux virtual machine as a syslog forwarder and how to implement the above stated solution as a whole: -
https://blog.johnjoyner.net/connect-your-firewall-to-azure-log-analytics-for-security-insights/
https://accountabilit.com/azure-log-analytics-best-syslog-destination/
We have an appservice hosting some odata api's in Azure. We are running an instance in Central US and another in East US 2. We have a Traffic Manager profile set up so a single url is balanced between the two instances. There is an intermittent issue, is there a way to hit a specific server as the endpoint to test them?
If you want to hit a specific server, you can directly access the instance with each instance domain name. Since Azure Traffic Manager works based on DNS, you can verify Traffic Manager settings using the tools like nslookup or dig to resolve DNS names. To effectively test a performance traffic routing method, you must have clients located in different parts of the world.
About the performance, please note that
The only performance impact that Traffic Manager can have on your
website is the initial DNS lookup.
Traffic does NOT flow through Traffic Manager. Once the DNS lookup
completes, the client has an IP address for an instance of your web
site. The client connects directly to that address and does not pass
through Traffic Manager. The Traffic Manager policy you choose has no
influence on the DNS performance. However, a Performance
routing-method can negatively impact the application experience. For
example, if your policy redirects traffic from North America to an
instance hosted in Asia, the network latency for those sessions may be
a performance issue.
You may set the DNS TTL value low so that changes propagate quickly (for example, 30 seconds).
In addition, there are sample tools to measure DNS performance.
To troubleshoot a probe failure, you need a tool that shows the HTTP status code return from the probe URL. There are many tools available that show you the raw HTTP response.
Fiddler
curl
wget
Also, you can use the Network tab of the F12 Debugging Tools in Internet Explorer to view the HTTP responses.
Hope this information could help you.
We are moving a workflow of our business to Azure. I currently have two VMs as an HA pair behind an internal load balancer in the North Central US Region as my production environment. I have mirrored this architecture in the South Central US Region for disaster recovery purposes. A vendor recommended I place an Azure Traffic Manager in front of the ILBs for automatic failover, but it appears that I cannot spec ILBs as endpoints for ATM. (For clarity, all connections to these ILBs are through VPNs.)
Our current plan is to put the IPs for both ILBs in a custom-built appliance placed on-prem, and the failover would happen on that appliance. However, it would greatly simplify things if we could present a single IP to that appliance, and let the failover happen in Azure instead.
Is there an Azure product or service, or perhaps more appropriate architecture that would allow for a single IP to be presented to the customer, but allow for automatic failover across regions?
It seems that you could configure an application gateway with an internal load balancer (ILB) endpoint. In this case, you will have a private frontend IP configuration for an Application Gateway. The APPGW will be deployed in a dedicated subnet, it will exist on the same VNet with your internal backend VMs. Please note in this case you can directly add the private VMs as the backends instead of internal load balancer frontend IP address because of private APPGW itself is an internal load balancer.
Moreover, APPGW also could configure a public frontend IP configuration, if so, you can configure the APPGW public frontend IP as the endpoints of the Azure traffic manager.
Hope this could help you.
So I have my website set up, call it www.mywebsite.com. I have my Traffic Manager set up so that www.mywebsite.com points to mytrafficmanager.trafficmanager.com.
The Traffic Manager then points to my two on-premise web front-ends web1.mywebsite.com and web2.mywebsite.com. It also has an endpoint of a Azure Web App.
It is set up to do a Priority fail over: web1, then if that fails to web2, and if they are both down, to fail over to the Azure Web App.
My question is this: If I get a DDoS attack on www.mywebsite.com, what would happen? Would the on-premise servers go down, and then it would fail over to the Azure Web App (which is set up to scale appropriately to hopefully mitigate a DDoS attack). Or would it not be able to route the traffic properly?
See MSDN forum topic for answer: https://social.msdn.microsoft.com/Forums/en-US/92733178-f305-4994-b954-67da945f40a7/azure-traffic-manager-and-ddos-attacks?forum=WAVirtualMachinesVirtualNetwork
Azure Connect is a service found on the older Azure.com portal and allows connectivity between on-premise and cloud servers/roles/resources. It creates a virtual IP (overlay) network - pretty much a VPN.
Azure Virtual Network (found on the new Azure portal) is ALSO touted as a VPN solution for also the same purpose however the configuration seems a lot twisted (although with a pretty UI).
I'm confused how these two product stack up against each other. Googling and searching MSDN didn't reveal much information either.
What are the differences between them and the target use-cases? Are they expected to be merged into one product down the road?
The use case for us is a WebRole that's running as a cloud service, whose REST/Web API services are consumed by machines on a private network. Azure Connect or Azure Virtual Network would (should?) provide the underlying connectivity between them.
Azure Connect allows users to connect Azure applications with on-premise servers in a super simple and quick way. It does not require VPN devices, it does not require user to have network knowledge, it does not require/assume user have access to network infrastructure (e.g. ability to configure the firewall at company's edge firewall). You express your connectivity intent (e.g. Azure service x should connect to a set of machines (machine group) y on-premise) in the management portal, Azure Connect does the rest for you. It is also very flexible in that you can change the network and connectivity policy at any time via the portal, without requiring redeployment of your app or any change on-premise. e.g. you can make Azure service x to connect to machine group z on-premise instead of y, once you make that change in portal, the rest happens automatically, machines in y are not long accessible to/from Azure. Azure Connect uses endpoint software to manage all the network connectivity for users, so you do have to install endpoint software. But it supports many different automatic deployment options including using Microsoft Update.
Azure Virtual Network allows user to extend part of their on-premise infrastructure to your Azure virtual network via standard site-to-site IPSEC connection. You must have an internet facing VPN device at on-premise side. The solution also assumes you have network knowledge - you will be asked to specify the network address range you will be using at both Azure and on-premise sides, you will must launch a VPN gateway at Azure side and manage the IPSEC connection. It does not require install endpoint software on servers, you are responsible for setting up routes to route the traffic from VPN device to servers and vice versa.
The two technologies complement each other, they are suitable for different scenarios.