April 13, 2015 at 09:58

Setting up volume replication in Windows Server vNext

• Microsoft Blog

• Recovery Mode

Good day to all!

Today I would like to tell you about a very interesting feature, which will be presented in the new Windows versions Server vNEXT, and which is already available for testing and testing in preview version Technical Preview, namely about replication at the volume level. In WS vNEXT this feature is now called Storage Replica. What kind of animal is this and what to eat it with - details under the cut.

Replication options and options

Storage replication, Storage Replica (SR) is new feature in Windows Server, which allows block synchronous (and in some cases asynchronous) replication at the volume level between clusters or Windows servers Server vNEXT. The SMB3 protocol is used as transport.

Currently, the “Server-to-Server” and “Stretch Cluster” replication options are supported. Replication at the Cluster-to-Cluster level has not yet been implemented, but is in the plans. Since replication occurs at the block level, the mechanism does not particularly care about the type of equipment on which it is deployed. file system. Replication can be either synchronous or asynchronous (so far only in the “Server-Server” scenario). TCP/IP or RDMA can be used as the network communication mechanism. Data deduplication and BitLocker-based encryption mechanisms can be used on top of the replica. This wonderful disaster- and fault-tolerant miracle of technology is currently configured exclusively through PowerShell. To carry out the process it is also necessary to have open ports TCP 445 or TCP 5445, be members of the same domain (the object of influence from this point of view is the host, and volumes are replicated between hosts, and volume replication scenarios within the same host are also possible). It is also important to remember that replication is only possible for data volumes, but not for the system volume - in other words, it is technically impossible to replicate “Disk C:”, and this technology was not developed for this purpose. This technology is designed to provide zero data loss (in the case of synchronous replication) or close to zero data loss (asynchronous scenario).

I also want to immediately note that there are also certain requirements for the channel: at least one 10 Gbps connection on each file server. For reliability, it would be a good idea to make sure that sending an unfragmented ICMP packet of 1472 bytes in size passes successfully without loss over a 5-minute interval.

It is also worth noting that to use for replication both as a target and as a source, removable media a la USB drive, you can’t. You will also need rights at the level of the built-in administrators group.
For testing purposes, you can try out all the mechanisms on a VM - just remember that virtual disks in such a scenario should be of a fixed type and not dynamically extensible.

Setting up Server-to-Server replication

Well, after familiarizing yourself with the introductory process of setting up volume replication, let’s set up Server-to-Server replication. Let me just remind you that the server is in preview - and this mechanism should not be used for combat data now. Each participating server must have a role installed "File Server" and function "Storage Replica" or "Windows Volume Replication"(depending on the server build.

After that, on one of the participating servers, run the PowerShell cmdlet with admin rights:

New-SRPartnership -SourceComputerName sr-srv05 -SourceRGName rg01 -SourceVolumeName d: -SourceLogVolumeName e: -DestinationComputerName sr-srv06 -DestinationRGName rg02 -DestinationVolumeName d: -DestinationLogVolumeName e: -LogSizeInBytes 8 gb.
In my example, two servers are involved: sr-srv05 and sr-srv06, a separate volume is allocated for log files (it should be one gigabyte smaller in size than the replication volume and the source and target volumes.
To verify that replication has been successfully configured, run the following cmdlet on both participating servers:

Get-WinEvent -LogName *WVR/admin -max 20 | fl

The presence of events 2200, 5005, 5015, 5001 and 5009 will be a sign of success.
If you need more detailed meter data (Get-Counter), then here is their list:

\Storage Replication Statistics(*)\Total Bytes Received
\Storage Replication Statistics(*)\Total Bytes Sent
\Storage Replication Statistics(*)\Avg. Network Send Latency
\Storage Replication Statistics(*)\Replication State
\Storage Replication Statistics(*)\Avg. Network Receive Latency
\Storage Replication Statistics(*)\Last Recovery Elapsed Time
\Storage Replication Statistics(*)\Number of Flushed Recovery Transactions
\Storage Replication Statistics(*)\Number of Recovery Transactions
\Storage Replication Statistics(*)\Number of Flushed Replication Transactions
\Storage Replication Statistics(*)\Number of Replication Transactions
\Storage Replication Statistics(*)\Max. Log Sequence Number
\Storage Replication Statistics(*)\Number of Messages Received
\Storage Replication Statistics(*)\Number of Messages Sent
\Storage Replication Application I/O Statistics(*)\Number of Received App Write Irps
\Storage Replication Application I/O Statistics(*)\Avg. Number of Irps/IoContext
\Storage Replication Application I/O Statistics(*)\Avg. App Write Latency
\Storage Replication Application I/O Statistics(*)\Avg. App Read Latency

It is also worth adding that in Windows Server Preview you cannot re-configure replication on volumes where it was present and then disabled.

Processes for displaying the course of events may be inaccurate and may not reflect complete reality - it is better to look at the counters.

Well, basically - that's all!

Basic and easy setup Volume replication in Windows Server looks like this!
Try it and see you again on the IT front.

Sincerely,

Fireman
Georgy A. Gadzhiev

Data from remote offices is often accumulated and combined into central office. The same way, you can replicate data to remote offices. The technology for this is called “Data Replication” and is supported by Microinvest products.

Basic provisions

Data replication – modern technology data management at several points, which builds general system data processing and consolidation. IN general outline, Replication is a process in which data is recorded and stored at the top of individual servers, but through information flow management, the results are organized into a central server.

Types of replication

There is a division of replications by time:

• Synchronous replication
• Asynchronous replication

Separation of replications by task:

• Master-Slave Replication
• Replication with peer servers (Multi Master)

Synchronous replication

Synchronous replication takes place in real time, information is multiplied on all servers. The peculiarity of synchronous replication is that if the connection between the servers is lost, no one reflects the changes, the cycle stops and the process practically cannot be continued. It is necessary that all data is 100% identical for all servers and clients. This mode is not used in real trading systems, because dependent on connection.

Asynchronous replication

Asynchronous replication is a technology in which data is stored in local server, which, for its part, takes care of passing them on to the next one and passes only the difference. This is the right technology for building a trading system, because... there is no requirement for uninterrupted communication, and data is transmitted as soon as possible, but not necessarily in real time.

Master-Slave Replication

Master-Slave replication depends on one central Master server, which accumulates all data and transmits the difference to the slave servers. Thus, the Master server always has an up-to-date copy of the data, while the Slave servers wait for changes and obey the information sent from the Master. They update their data late. The advantage of this technology is simple execution, the disadvantage is that records are always made in the Master server, which requires constant communication with this server. If connection will be lost with a central server, the system will not be able to display new transactions, but it will be possible to make inquiries. This technology is implemented in MySQL server and is often used in trading systems. Typically, the Master server is located in the company's central office.

Replication with Peer Servers

Replication with peer servers – advanced technology, where each server is independent and, at the same time, part shared network. With this technology, there is also a central server that manages communications between other servers. The advantage of technology is complete independence from communication in work. When there is a connection, the data is transferred to the central server. Slave servers transmit only their differences and do not load the data exchange channel. When there is no connection between servers, data is accumulated locally for later merging when communication is restored. This technology is called Transactional Merge and is implemented in MS SQL Server.

Replication in Microinvest Warehouse Pro

Some Helpful Resources

• Documentation for all products;
• Microinvest technical support forum, where you can quickly get an answer to your question;
• Examples of automation of restaurants and trade based on Microinvest in Russia and the CIS countries;

Replication- one of the techniques for scaling databases. This technique consists of the fact that data from one database server is constantly copied (replicated) to one or more others (called replicas). It becomes possible for an application to use not one server to process all requests, but several. This makes it possible to distribute the load from one server to several.

There are two main approaches when working with data replication:

• Master-Slave replication;
• Master-Master replication.

Master-Slave replication

This approach highlights one main server database, which is called the Master. All changes in data (any MySQL queries INSERT/UPDATE/DELETE). The slave server constantly copies all changes from the Master. Data reading requests are sent from the application to the Slave server ( SELECT queries). Thus, the Master server is responsible for changing data, and the Slave is responsible for reading.

In the application you need to use two connections - one for the Master, the second for the Slave:

$master= mysql_connect("10.10.0.1", "root", "pwd"); $slave= mysql_connect("10.10.0.2", "root", "pwd"); # ... mysql_query("INSERT INTO users ...", $master); # ... $q = mysql_query("SELECT * FROM photos ...", $slave);

# We use two connections - for Master and Slave - for writing and reading, respectively

Multiple Slaves

The advantage of this type of replication is that you can use more than one Slave. Typically, you should use no more than 20 Slave servers when working with one Master.

Then from the application you randomly select one of the Slaves to process requests:

$slaves = [ "10.10.0.2", "10.10.0.3", "10.10.0.4", ];$slave = mysql_connect( $slaves, "root", "pwd"); # ... mysql_query("INSERT INTO users ...", $master); # ... $q = mysql_query("SELECT * FROM photos ...", $slave);

Replication delay

Asynchronous replication means that data may appear on the Slave with a slight delay. Therefore, in sequential operations it is necessary to use reading from the Master to obtain the latest data:

id = 7", $master); $q = mysql_query("SELECT * FROM users WHERE id = 7", $master); # ... $q = mysql_query("SELECT * FROM photos ...", $slave);

# When accessing mutable data, you must use a Master connection

Failure

If the Slave fails, it is enough to simply switch the entire application to work with the Master. After this, restore replication on the Slave and start it again.

If the Master fails, you need to switch all operations (both reading and writing) to the Slave. Thus he will become the new Master. After restoring the old Master, set up a replica on it, and it will become the new Slave.

Reservation

Much more often, Master-Slave replication is used not for scaling, but for redundancy. In this case, the Master Server processes all requests from the application. The slave server operates in passive mode. But if the Master fails, all operations are switched to the Slave.

Master-Master replication

In this scheme, any of the servers can be used for both reading and writing:

When using this type of replication, it is enough to select a random connection from the available Wizards:

$masters = [ "10.10.0.1", "10.10.0.2", "10.10.0.3", ];$master = mysql_connect( $masters, "root", "pwd"); # ... mysql_query("INSERT INTO users ...", $master);

# Select a random Master to handle connections

Failure

Possible breakdowns make Master-Master replication unattractive. The failure of one of the servers almost always leads to the loss of some data. Subsequent recovery is also greatly hampered by the need for manual analysis of data that was or was not copied.

Use Master-Master replication only as a last resort. Instead, it is better to use the “manual” replication technique described below.

Asynchronous replication

In MySQL, replication works asynchronously. This means that the application does not know how quickly the data will appear on the Slave.

The replication lag can be very small or very large. Typically, an increase in latency indicates that the servers cannot cope with the current load and need to be scaled further, for example by technicians

What's good about using the DFS namespace? The fact that all resources for users lie in one single directory, which is not tied to server names, and all questions regarding the physical location of file resources do not concern users. For them, the path to the working folder always remains unchanged. DFS also allows you to use data replication between several network folders and even distribution of users between file servers.

There is a certain program that uses a database and a file folder. In the database - paths to files, files, respectively, in a network folder.

The folder is more than a terabyte in total, there are a lot of files. The files are compressed audio and are sometimes quite small in size.

The operation of the program is critical to the functioning of the business, which means there is a need to organize a certain safety margin in case of hardware or software failure.

Database fault tolerance was achieved by using the Always On Availability Groups functionality on MS SQL 2012.

The easiest way to achieve fault tolerance for a network folder is to replicate the folder using DFS.

Separately, I would like to note that the root folder of the DFS namespace (DFS root) also needs to be protected from failure. In Windows Server 2008 and later, this is achieved without the use of clustering technologies. Simply after creating the root, we add another namespace server. For example, two domain controllers, also known as DFS namespace servers. If one of them is rebooted or broken, users will continue to use the DFS namespace and will not notice anything.

And so, we create the DFS root folder. We create a virtual folder structure for company departments. In the department folders, we create folders pointing to the final file resources on the file servers.

Now let's move on to setting up DFS replication for the folder we need.

To enable replication, we need to install in advance on the server where the folder will be located the “DFS replication” role and the “Remote Differential Compression” component.

Then, go to the MMC console “DFS Management”, select a folder and launch the replication wizard:
Specify the server:

Destination folder:
Create a replication group:

Select the server with the main copy of the data (this is relevant during primary replication):

Select the topology (if there are two servers, then there are no options):
We can choose the replication speed and schedule:

Let's finish:
Now we wait for the completion of the initial synchronization.

And so, replication is configured, we rub our hands together and within 24 hours we receive a complaint that the folders on the servers are different, which means replication does not work.

We spend a lot of time comparing folders and manually copying different pieces of information.

This is actually why people don’t like to use DFS replication.

This all happened because no one read the DFS setup manual. As I said, the folder takes up about a terabyte. There are many files that users work with through the program.

Folder replication occurs by using the hidden directory DfsrPrivate\Staging, and the quota mechanism is involved there. The default replication cache quota (Staging Folder) or “Intermediate quota” is 4 gigabytes, which is catastrophically low for the data volumes indicated above. That's why replication doesn't work.

How to raise? Guessing is not our method. Let's see what they write on Technet.

2003 server – Staging quota should be the size of the nine largest files in the replication folder.

2008 and 2008 R2 – Staging quota should be the size of the 32 largest files in the replication folder.

PowerShell will help us here.

We write a command (replace<путь>to the path to the desired folder):

“(0:N0)” -f((get-childitem<ПУТЬ>-recurse | sort-object length -descending | select-object -first 32 | measure-object -property length -sum).sum /1gb)

We get the total volume of the 32 largest files in gigabytes, rounded to the nearest whole number. Go to replication settings:

We apply. As an option, we also increase the quota for conflicts and deleted files.

Don't forget to repeat the setup for the second server.

P.S: In my case, DFSR was not applicable, since the application selects a master from the working machines where it is running by changing a specific file that is in the file storage, along with the application data. The file is updated more than once per second with minor information. The time and name of the master machine are written to the file. As a result, the file is updated simultaneously on all servers and its replication fails, since DFSR cannot determine which version of the file is correct. In addition, several machines simultaneously consider themselves the master of operations, which leads to problems in the application.
If developers stuck to the “server-witness” idea and moved the file to a separate resource, without combining it with application data, they could save tenfold on simplifying the hardware infrastructure.
As a result, you will have to maintain the folder using an MSFT cluster or Fault Tolerance in VSphere.

Data can be replicated both within a local network and through a global WAN network. DFSR technology was designed with slow WAN networks in mind and works just as reliably over the Internet as it does within the same building.
The question arises - how does this function essentially differ from the DFS namespace? Its main difference is the presence of the Remote differential compression algorithm (RDC) function, which is used to replicate changes. The basic idea of ​​this algorithm is that only the changed parts of the file are replicated. For example, if we have a large text document, and we added several pages in the middle of the document, then only these few pages will be transferred over the network during the next synchronization session. Thus, it is most preferable to use DFS replication in slow networks, for example, to replicate one (several) folders between remotely located offices with slow channels.
Data replication is resilient to network problems. If communication with the remote machine is interrupted, then replication will, of course, stop. But as soon as the network is working again, replication will begin from the place where it was interrupted.
Let's look at step-by-step instructions for setting up DFS replication. The first thing you need to do is.
After this, we create a replication group (a replication group is a set of servers, called members, that participate in the replication of one or more replicated folders. A replicated folder is a folder for which synchronization is supported on each of the members), to do this, right-click on "Replications", select "New replication group..."

In the type of replicated replication group, I recommend specifying "Universal Replication Group", since this type is more flexible in future use.


In the next window, specify the name of the replication group, write a comment (optional) and see if the domain is being used (if your organization uses several domains).

Then we indicate the servers that will be part of the replication group (there can be two or more of them).


In the topology selection window, indicate the type of connection topology, reading the comments under each type, select the one that suits you and click "Further". This example uses "Full Grid".


In the next window, select the time at which replication will be performed. In this example, I want replication to run around the clock, for this I leave everything at default.


In the window "Primary Replication Member" We indicate the server on which the data is stored.


In the next window, specify the folder that needs to be replicated.


Then we indicate the folder to which we need to replicate (on another server).


After this, we look through all the specified settings and if everything is correct, click "Create".


Now in the category "Replications" we see the created replication Common.

In order to start replication manually, you need to click on replication, in this example "Common", then go to the tab "Connections" and right-click on any connection and select "Replicate Now".