April 13, 2015 at 09:58Configure Volume Replication on Windows Server vNext
Good day to all!
Today I would like to tell you about a very interesting feature that will be introduced in the new version of Windows Server vNEXT, and which is already available for testing and testing in the preliminary version of Technical Preview, namely, about replication at the volume level. In WS vNEXT, this feature is now called Storage Replica. What kind of animal it is and what it is with - details under the cut.
Storage Replication, Storage Replica (SR) is a new feature in Windows Server that enables block-level synchronous (and in some cases asynchronous) volume-level replication between clusters or Windows Server vNEXT servers. As transport, the SMB3 protocol is used.
Currently, Server-Server and Stretch Cluster replication options are supported. Cluster-Cluster level replication has not yet been implemented, but is present in the plans. Since replication occurs at the block level, the mechanism does not really care about the type of equipment on which the file system is deployed. Replication can be either synchronous or asynchronous (so far only in the Server-to-Server scenario). As a network communication mechanism, TCP / IP or RDMA can be used. BitLocker-based data deduplication and encryption mechanisms can be applied on top of the replica. This wonderful disaster and fault-tolerant miracle of technology is configured so far exclusively through PowerShell. To implement the process, you also need to have open TCP 445 or TCP 5445 ports, be members of the same domain (the object of influence from this point of view is the host, and volumes between the hosts are replicated, and scripts for replicating volumes within the same host are also possible). It is also important to remember that replication is possible only for data volumes, but not for a 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 level of data loss (in the case of synchronous replication) or close to zero level of data loss (asynchronous scenario). and not for this purpose this technology was developed. This technology is designed to provide zero level of data loss (in the case of synchronous replication) or close to zero level of data loss (asynchronous scenario). and not for this purpose this technology was developed. This technology is designed to provide zero level of data loss (in the case of synchronous replication) or close to zero level of data loss (asynchronous scenario).
I also want to note right away that there are also certain requirements for the channel: at least one 10 Gb / s connection on each file server. For reliability, it would be nice to make sure that the sending of an unfragmented ICMP packet of 1472 bytes in size is successful without loss over a 5-minute interval.
It is also worth noting that it is not possible to use removable media a la USB stick for replication, either as a target or as a source. You will also need permissions at the level of the built-in group of administrators.
For testing purposes, you can try all the mechanisms on the VM - just remember that virtual disks in this scenario should be of a fixed type, and not dynamically expanding.
Well, after familiarizing yourself with the introductory notes on the volume replication configuration process, let's configure Server-to-Server replication. I’ll just remind you that the server is in preview — and it’s not worth using this mechanism for combat data now. On each participating server, the “File Server” role and the “Storage Replica” or “Windows Volume Replication” function must be installed (depending on the build . server
After that, one of the participating servers execute PowerShell cmdlet with the admin rights:
In my example involves two servers: sr-srv05 and sr-srv06, allocated a separate volume under the log files (it should be the size of one gigabyte less than the replication volume and source volumes and target volumes.
To verify the success of replication setup executed sequentially by both participating servers, run the following cmdlet: The presence of events 2200, 5005, 5015, 5001, and 5009 will be a sign of success. If you need more detailed data on the counters (Get-Counter) , then here is a list of them: • \ 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
Sent
• \ 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’s also worth adding that in Windows Server Preview it’s impossible to configure replication again on the volumes where it was and then was disabled.
The process of displaying the course of events may be inaccurate and not reflect the full reality - it is better to look at the counters.
Well, in principle - that’s all!
Basic and simple volume replication setup in Windows Server looks like this!
Try to see you again on the IT front.
Sincerely,
Fireman
George A. Gadzhiev
Today I would like to tell you about a very interesting feature that will be introduced in the new version of Windows Server vNEXT, and which is already available for testing and testing in the preliminary version of Technical Preview, namely, about replication at the volume level. In WS vNEXT, this feature is now called Storage Replica. What kind of animal it is and what it is with - details under the cut.
Replication Options and Features
Storage Replication, Storage Replica (SR) is a new feature in Windows Server that enables block-level synchronous (and in some cases asynchronous) volume-level replication between clusters or Windows Server vNEXT servers. As transport, the SMB3 protocol is used.
Currently, Server-Server and Stretch Cluster replication options are supported. Cluster-Cluster level replication has not yet been implemented, but is present in the plans. Since replication occurs at the block level, the mechanism does not really care about the type of equipment on which the file system is deployed. Replication can be either synchronous or asynchronous (so far only in the Server-to-Server scenario). As a network communication mechanism, TCP / IP or RDMA can be used. BitLocker-based data deduplication and encryption mechanisms can be applied on top of the replica. This wonderful disaster and fault-tolerant miracle of technology is configured so far exclusively through PowerShell. To implement the process, you also need to have open TCP 445 or TCP 5445 ports, be members of the same domain (the object of influence from this point of view is the host, and volumes between the hosts are replicated, and scripts for replicating volumes within the same host are also possible). It is also important to remember that replication is possible only for data volumes, but not for a 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 level of data loss (in the case of synchronous replication) or close to zero level of data loss (asynchronous scenario). and not for this purpose this technology was developed. This technology is designed to provide zero level of data loss (in the case of synchronous replication) or close to zero level of data loss (asynchronous scenario). and not for this purpose this technology was developed. This technology is designed to provide zero level of data loss (in the case of synchronous replication) or close to zero level of data loss (asynchronous scenario).
I also want to note right away that there are also certain requirements for the channel: at least one 10 Gb / s connection on each file server. For reliability, it would be nice to make sure that the sending of an unfragmented ICMP packet of 1472 bytes in size is successful without loss over a 5-minute interval.
It is also worth noting that it is not possible to use removable media a la USB stick for replication, either as a target or as a source. You will also need permissions at the level of the built-in group of administrators.
For testing purposes, you can try all the mechanisms on the VM - just remember that virtual disks in this scenario should be of a fixed type, and not dynamically expanding.
Configuring Server-to-Server Replication
Well, after familiarizing yourself with the introductory notes on the volume replication configuration process, let's configure Server-to-Server replication. I’ll just remind you that the server is in preview — and it’s not worth using this mechanism for combat data now. On each participating server, the “File Server” role and the “Storage Replica” or “Windows Volume Replication” function must be installed (depending on the build . server
After that, one of the participating servers execute PowerShell cmdlet with the admin rights:
New-SRPartnership -SourceComputerName sr-srv05 -SourceRGName rg01 -SourceVolumeName d: -SourceLogVolumeName e: -DestinationComputerName sr-srv06 -DestinationRGName rg02 -DestinationVolumeName d: -DestinationLogVolumeName e: -LogSizeInBytes 8gb. In my example involves two servers: sr-srv05 and sr-srv06, allocated a separate volume under the log files (it should be the size of one gigabyte less than the replication volume and source volumes and target volumes.
To verify the success of replication setup executed sequentially by both participating servers, run the following cmdlet: The presence of events 2200, 5005, 5015, 5001, and 5009 will be a sign of success. If you need more detailed data on the counters (Get-Counter) , then here is a list of them: • \ 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
Get-WinEvent -LogName *WVR/admin -max 20 | fl
• \ 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
Sent
• \ 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’s also worth adding that in Windows Server Preview it’s impossible to configure replication again on the volumes where it was and then was disabled.
The process of displaying the course of events may be inaccurate and not reflect the full reality - it is better to look at the counters.
Well, in principle - that’s all!
Basic and simple volume replication setup in Windows Server looks like this!
Try to see you again on the IT front.
Sincerely,
Fireman
George A. Gadzhiev
