This afternoon I have uploaded my WorkerRole in Cloud Service on Azure, this service run on VM with Windows Server 2012. I have realized that WorkerRole can't get query from Databases (BigQuery, TSQL). When I have read the service log in VM I have seen the following error:
The VM and host networking components failed to negotiate protocol version '5.0'
I think that Hyper-V-vsc has something to do. Anybody knows what happens?
Thanks,
Roger
First thing I could check is to make sure the databases you are trying to connect too have whitelisted the VIP for the cloud service you're connecting from. And if you haven't already, remote into an instance of the worker and try reaching the DB's using a thin a client UI as you can.
In my experience, these issues are usually on the db end. Azure doesn't do much with blocking outbound connections. Those that fail are usually more a matter of protocol (UDP multicast for example).
Related
This has been previously working but stopped recently. I have a Wordpress container running in an AKS pod that connects to Azure Database for MySQL Server Basic Pricing Tier. Recently the container is unable to connect. I have tried to whitelist all IPs in the MySQL Connection Security to rule that out 0.0.0.0 - 255.255.255.255 but that did not seem to help.
When exec into the pod and install a MySQL client and try to connect to the MySQL Server I see an error:
ERROR 9009 (28000): Client connections to Basic tier servers through Virtual Network Service Endpoints are not supported. Virtual Network Service Endpoints are supported for General Purpose and Memory Optimized severs.
I don't understand why this was working in the past and stopped now. Is this error message correct and is it basically telling you either upgrade (which I don't think you can just do in the portal to scale up like you would do for SQL Server), or you will not be able to access the DB. To upgrade would I have to backup the DB, create a new server in the General Purpose Pricing Tier and restore, so no smooth Scale Up path?
I don't seem to have the VNet option in Azure Portal
EDIT:
I have since found this post on microsoft forum and what that is saying is that you have to upgrade to GP pricing tier. So going from £19.805/month to £104.789/month. Just wow.
EDIT:
The way to get it work with MySQL Basic Tier was to disable Service Endpoints in AKS VNet as suggested in the accepted answer. The problem was that the SQL Server was configured to use Service Endpoints. To get that going after removing the service endpoints I had to disable service endpoints in the SQL Server. Not too happy with that but I guess you can't have both, your Basic Tier MySQL Server and decent security. If you want both, you will have to pay :(
It was never working, unless you were not using Service Endpoints. If you switch those off - it should resume working.
I have an Azure virtual machine, on which a process listens on a certain port. A Node.js application on my local computer is able to connect to this process using the VM's public IP address. But the same Node.js application, deployed as an app service on Azure, is apparently not able to connect using any IP address, despite the fact that the VM allows all incoming traffic on all ports.
(Details: The VM process is running "q" (kdb+), and the Node.js application is using the "node-q" package to connect to it. Both the Azure VM and the Azure app service are Linux, but the local version of the app service is on Windows. The Azure app service is able to connect to my Azure SQL database.)
Any insights into this problem would be appreciated.
There are many reasons for Bad gateway error, probably you could verify these factors on your side:
Azure VM side. Make sure the Azure VM is running and the process port is listening when you request a connection from an application. You could run sudo netstat -plnt on Linux VM to check the listening ports. Or, a server can crash if it has exhausted its memory, due to a multitude of visitors on site or a DDOS attack.
Firewall blocks a request. You should allow all incoming traffic or Azure web app service outbound traffic on this listening port on the VM. In this scenario, you could verify the Network Security Group configuration for the VM and firewall inside the VM if you have. You could find NSG settings by clicking Virtual machine--Settings---Networking---inbound port rules on the Azure portal.
Faulty programming. It seems the Node.js application could work locally.
Temporary issue. Sometimes, there is no real issue but your browser thinks there is one thanks to an issue with your browser, a problem with your networking equipment, or some other reasons. You could refresh your web browser or clear cache and cookies to get the page back what you are looking for. More details you can refer to fixing 502 error.
If you still have any question, feel free to let me know.
It was faulty deployment. I didn't include all dependencies in the upload to Azure. Thank you.
I'm taking my first foray into Azure Service Fabric using a cluster hosted in Azure. I've successfully deployed my cluster via ARM template, which includes the cluster manager resource, VMs for hosting Service Fabric, a Load Balancer, an IP Address and several storage accounts. I've successfully configured the certificate for the management interface and I've successfully written and deployed an application to my cluster. However, when I try to connect to my API via Postman (or even via browser, e.g. Chrome) the connection invariably times out and does not get a response. I've double checked all of my settings for the Load Balancer and traffic should be getting through since I've configured my load balancing rules using the same port for the front and back ends to use the same port for my API in Service Fabric. Can anyone provide me with some tips for how to troubleshoot this situation and find out where exactly the connection problem lies ?
To clarify, I've examined the documentation here, here and here
Have you tried logging in to one of your service fabric nodes via remote desktop and calling your API directly from the VM? I have found that if I can confirm it's working directly on a node, the issue likely lies within the LB or potentially an NSG.
Created an azure MVC website, from service (controller) code we are connecting to an on-premise sql server using Azure Hybrid Connection. Intermittently we are facing below issue.
"A transport-level error has occurred when receiving results from the
server. (provider: TCP Provider, error: 0 - The specified network name
is no longer available.)"
Please provide suggestions to resolve this issue.
You can try following solutions :
Try increasing connection time-out.
check if remote connection is enabled.
Try adding firewall exception.
First of all the error means either the networks has some extra latency, the database is down or you may have too many concurrent connections open the database.
(Make sure you are closing all open datareaders.)
also it may be due to this
These are transient faults and are to be expected in the cloud. Implementing defensive programming is usually a must in the cloud. Try using some retry logic. Microsoft's transient fault exception library is an excellent start. Though meant primarily for SQL Azure and Azure Service bus, you can use the library for SQL IaaS.
In my opinion, 98% sure, because I recently had the same experience, it is a network issue from the server provider.
For instance: if you are rent the server from Ionos, by default all remote connections are blocked, even though you disable the firewall in the server. You still won't be able to connect remotely. You can, however, do your work on the server without any problem.
To connect remotely, you have to contact the server provider. They will explain how to enable firewall ports from your control panel.
I contacted my server provider as I almost get frustrated. Here was their response.
enter image description here
After this, every permitted client can connect remotely to the server.
I wish you success.
We are running some long-running test apps with Azure Service Bus relay over http, hosted in a windows service and most of the time, these run fine for 2-3 days. However every so often an internal network glich may occur (e.g. firewall reboots) that kills the internet connection.
At this point, the relay is dropped in Azure and our web app can no longer communicate with the on-premise service.
I would have thought that the Azure relay client was fault-tolerant - in that if it realises that it's lost connection with Azure then it will re-establish the connection andf if it can't keep trying until it can.. but it appears that this is not the case. This seems pretty fundamental...?
Only once have I ever seen a "System.ServiceModel.CommunicationException" where the service can't communicate on the internet, and that was when the client was starting up and trying to establish the connection in the first place.
Is there any advice or feedback on handling transient disconnections through the relay service (as it's a cloud --> on-prem direction then the client can't AFAIK ping the server).
If you are still experiencing issues, you may want to contact Azure support to understand why it is disconnecting. The Relay client should reconnect if something happens to the existing connection.
You may want to add ConnectionStatusBehavior to your ChannelFactory to have it output when the status for the connection changes. It will contain the error that caused it to change status.
var connectionStatusBehavior = new ConnectionStatusBehavior();
connectionStatusBehavior.Online += ConnectionStatusOnlineMethod;
connectionStatusBehavior.Offline += ConnectionStatusOfflineMethod;
channelFactory.Endpoint.Behaviors.Add(connectionStatusBehavior);
This issue is solved by Microsoft in version 2.6.5 of Microsoft Azure Service Bus dll. After 1 month of testing it seems to work.