I have 2 appservers and 1 Db server running in Azure. I have created a CloudService and put the app servers in that. I have created a Availablity set for app server and added the appservers in it.
Now comes the issue, I cannot add Db server in the same availability set, because they are not in the same cloud service as appservers. So Azure may reboot the dbserver anytime and cause an outage. How to solve this.
Do I need add one more DB server and replicate the DB and add them to a new availability set?
If 1 is yes, then I should make my application smarter when the primary Db server goes down?
Any betterways?
Availability sets are limited to Virtual Machines within a single cloud service. Even if you added your database server in the same cloud service as your app servers, this still wouldn't provide HA for your DB since you can have the host OS updated, bringing your DB server down for a short time.
The only way to have HA is to run multiple DB servers. If you run SQL Server, you can set up an Always On configuration (see here for documentation). EDIT I missed the comment about you using MySQL. MySQL has HA configurations, but I haven't set one up before; you'd need to set this up across multiple VMs, and you should consider putting all nodes in an Availability Set, so that any Host OS updates will be staggered across the VMs, rather than being applied at once (and also separating the VMs across different fault domains).
Related
I have an application in mind that would be built using node, mongodb + other db, kubernetes , RabbitMQ, docker and react as a front end. The application will be built in a microservice architecture. We all know that for a monolith app all you need is one DB (MongoDB, MySQL etc etc) but for a micro one you can have multiple databases. My question would be, do I need to buy multiple, separate databases and connect each service to them ? or how does it work in a micro-services design.
At the moment a I have a sample microservices app that is running on my local machine using docker and its connected to multiple databases or database/service. I am just to trying to get an idea on how does this work with companies like DigitalOcean or AWS.
Any input on this would be great.
I am just trying to figure out how this going to work when it comes to production later so that I am ware of cost and deployments. I have done some research on Digital ocean, AWS etc etc but I still can figure out how do they work.
thanks in advance.
You don't need having multiple instances of DBMS running. You can easily use one VM with one MongoDB running on it.
When you scale you might want to have separate machines running DB instances for your services, but at start you may just separate it logically to ensure you do not communicate between services using DB.
Chris Richardson on his microservices.io website says:
There are a few different ways to keep a service’s
persistent data private. You do not need to
provision a database server for each service.
For example, if you are using a relational database
then the options are:
- Private-tables-per-service – each service owns a
set of tables that must only be accessed by that
service
- Schema-per-service – each service has a database
schema that’s private to that service
- Database-server-per-service – each service has
it’s own database server.
Source: https://microservices.io/patterns/data/database-per-service.html
I am running the mlflow registry using mlflow server (https://mlflow.org/docs/latest/model-registry.html). The server runs fine. If the server crashes for any reason it restart automatically. But for the time of restart the server is not available.
Is it possible to run multiple isntances in parallel behind a load balancer? Is this safe or could it be possible that there are any inconsistencies?
Yes, it's possible to have multiple instances of MLflow Tracker Service running behind a load balancer.
Because the Tracking server is stateless, you could have multiple instances log to a replicated primary DB as a store. A second hot standby can take over if the primary fails.
As for the documentation in how to set up replicated instances of your backend store will vary on which one you elect to use, we cannot definitely document all different scenarios and their configurations.
I would check the respective documentation of your backend DB and load balancer for how to federate requests to multiple instances of an MLflow tracking server, how to failover to a hot standby or replicated DB, or how to configure a hot-standby replicated DB instance.
The short of it: MLflow tracking server is stateless.
The above suggests active-passive. Can the server be run in active/active (load balancer sends request to any of the runnning instances)?
There are edge cases where a stateless system might have problems with multiple writers.
I am creating a WebService with C# Core 3.0 that is using MySQL and Redis, but I am not so familiar with Azure so I need advice about configuring everything.
I had MySQL hosted on AWS, but I am transferring it to Azure because I think that performance (speed) will be better on Azure because they will be on same data center. Right?
But, on my MySQL page Host is like '*.mysql.database.azure.com'. That means that every connection will go out of Azure, and than come back? I don't have some local IP for connection? Same question for Redis.
Do I need to configure some local network on Azure and will that impact speed on the app? And, is MySQL a good choice for Azure or should I try with another one?
I am just reading about Azure Virtual Networks. But as I understand it, VN's sole purpose is to isolate elements from the outside network?
You will get better performance if your my-sql instance and your app service are in the same region (basically the same data centre).
The connection string is mysql.database.azure.com, but remember the connection will be a TCP/IP connection, so the DNS lookup will realise that this address mysql.database.azure.com is in the same region (same data center). Then the TCP/IP connection will go to an internal IP.
You could use tcpping in your app service's kudo console to try this and see the result.
The basic rule is that you should group your app and database in the same region for better performance and cheaper cost (as Microsoft doesn't charge traffic within the same region).
Azure Virtual network is for a different purpose. For example, if you have some on premise database servers and you want to call these servers from azure, then VM could be helpful. But for the scenario you described, it is not really needed.
The company I work for has Microsoft azure support included, and if you or your company have support contract with them, you can raise questions directly to them and get really quick responses.
I'm in the process of migrating an existing website into Azure for a client. The current architecture is 4 web vm's mated to 4 sql server vms. One web vm per sql server vm. Complexity and cost is prohibiting us from migrating the sql server vm's into azure sql servers. These are read only databases and use log shipping to keep them synced.
I have easily published the asp.net application to an azure web app. My question is, how do I evenly distribute the web app instances to the 4 sql server vm's?
Depending on hourly traffic, I can see anywhere from 2 to 8 web app instances running at any given time. How can I evenly distribute the load to the 4 database vm's?
Depending on how you setup your environment you could put an Azure Internal Load Balancer (ILB) in place to load balance TCP 1433 across the four back-end SQL Database Servers.
You might need to tweak the distribution mode, but I'd run it first to see what the performance is like. If the Database is relatively static perhaps you could even consider using a VM Scale Set to scale out SQL based on load.
We are planning to migrate our Enterprise Application(s) from on-premises to Azure. Below are the high level details about our current infrastructure.
One Web Server hosting multiple WebSites (around 30 websites)
One Server with SSIS installed in it which processes huge data coming from multiple data sources and dumps the data into Pre-production database server explained in #3 below
Two Servers (Pre-production and Production) with SQL Server hosted in them where some jobs run on Pre-Produciton Server and the data gets replicated to the Production database server.
One Server where SSRS is hosted that uses data (and stored procedures) from Pre-Production database Server.
Could you please let us know if it is a good option to migrate the current infrastructe to PAAS? Is it really possible? We are also planning to leverage the other Azure features like Load Balancing on Web Servers and High availability on Production Database server with Active-Passive servers.
For migration scenarios, please see the following: https://azure.microsoft.com/en-us/documentation/articles/sql-database-cloud-migrate/