Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

Environments

The following are the platforms supported by FSR and the physical requirements of the target system.


Platforms

Works on Windows 2012 x64 or later, Linux CentOS 6.4, Ubuntu 16.04 LTS x64 or later platforms. The file system supports NTFS, ReFS, ext family (ext3 or higher), and xfs. (Old file systems such as FAT are not supported.)

CPU

Works with at least 2GHz, 4 core or higher x86/x64 compatible processor.


Memory

System memory

We recommend a minimum of 4 GB of system memory, with at least 30% of physical memory usage free. This is because, although it depends on the kernel, 70% of physical memory usage is typically the point at which the operating system will trigger paging to respond to a memory shortage. If paging is triggered on your system, you may experience system-wide I/O degradation, so you should consider this.

Memory buffer size

The memory buffer for replication is used to buffer the I/O load locally, and its size is basically obtained by the following formula

  • Size of the maximum bandwidth transferred per time (in seconds) * Timeout time (in seconds)

For 1 Gbps, you can get about 100 MB/s * 5 s = 500 MB, and you should be comfortable with 500 MB to 1 GB.

If you need to consider the fluctuating bandwidth of the WAN section, DRX buffering with DRX integration responds to WAN bottlenecks. If you don't have DRX integration, allocate a larger memory buffer size (5-10x the memory buffer) and consider configuring it as a file buffer if memory is not available (see below).

Disk

The default installation size is 2 GB, including installation files and log files, and if you configure a filebuffer, you'll need additional space of that size.

File buffer size

File buffer is a feature that allows you to use regular files for buffering purposes. However, using a file buffer involves file I/O to write to the buffer, which may result in performance degradation compared to traditional local I/O.

File buffers can be sized to fit your needs, and are typically sized between 5 and 10 times the size of a memory buffer.


How it works

  • It is based on active-passive clustering operation.
  • Supports one-way replication from primary to secondary nodes. Operating methods such as circular mirroring and dual primary mode are not supported.
  • Asynchronous replication is supported, but synchronous replication is not supported.



Functional scope

FSR basically aims to support replication for all file types and file I/O implemented in commercial file systems, but it is practically impossible to support all environments and file systems. We will expand the scope of support by first supporting the most used file systems and environments. And replication for some system files and special files is excluded from the support specification. The scope of the specific file replication function related to this will be described in detail according to the following classification.


File Types

The following file types are supported.

  • general files and directories
  • link files
    • soft link
    • hard link
    • junction, reparse point
  • sparse file
  • compressed file
  • encrypted file

The following special files will be supported in FSR version 1.1.

  • NTFS ADS(Alternate Data Stream)
  • NTFS TxF(Transaction File)

When a user specifies a replication target for an FSR, care must be taken to ensure that system files used at the OS level are not specified as replication targets. Even if there is normally no problem in replicating system files, care must be taken as it can cause operational problems if a deadlock occurs occasionally due to contention with file I/O of the OS during synchronization or replication.



I/O Types

Most of the I/O types supported by Windows and Linux are supported.

  • General I/O
    • Buffered I/O(Cached I/O)
    • Direct I/O(Non-Cached I/O)
  • Memory Mapped I/O
  • Special I/O
    • linux
      • Async I/O(aio)
      • Vector Write(writev)
      • Splice I/O
      • Uring I/O

Splice I/O in Linux is a special I/O that implements zero copy for high-speed data transfer. FSR can capture and replicate Splice I/O, but additional Copy Latency is required in the process of copying Splice I/O data for replication, resulting in performance degradation compared to original Splice I/O. This is an unavoidable technical limitation of implementing data replication. You should take this into account when replicating data from applications that use Splice I/O.


File Properties

Replicate the following file attributes.

  • File properties: read-only, hidden, system, directory, archive, sparse, compressed, encrypted
  • ACL: SID or account name of the source file
  • Time: modification time

It replicates most of the file attributes, but the file time attribute is only replicated for the modification time and not for other times. For example, it is technically impossible to match the file access times of the source and target.

  • Among the file attributes in Windows, the device attribute (FILE_ATTRIBUTE_DEVICE) and virtual attribute (FILE_ATTRIBUTE_VIRTUAL) are system-reserved attributes and are excluded from replication.
  • The following file attributes related to OneDrive added in Windows 10 are not supported.
    • FILE_ATTRIBUTE_RECALL_ON_OPEN
    • FILE_ATTRIBUTE_PINNED
    • FILE_ATTRIBUTE_UNPINNED
    • FILE_ATTRIBUTE_RECALL_ON_DATA_ACCESS



Shared Files

Fully real-time replication of files shared by Network File System (NFS) is subject to technical limitations. There is a limit to capturing real-time I/O just by filtering the local file system because the subject that changes the shared files can be multiple nodes.

Therefore, real-time replication is not implemented for shared files, and it is provided as a function to back up through periodic synchronization.







  • No labels