FSR 의 최적화는 로컬 I//O의 지연시간과 복제 트래픽 처리량 두 가지 측면에서 설명합니다.

지연시간

로컬 I/O 가 발행되어 디스크에 쓰여진 후 완료 되기 까지 소요된 시간을 응답시간 또는 지연시간(Latency)이라고 합니다. 지연시간이 작을 수록 I/O 회수가 증가 하므로 성능이 좋아집니다. 이와 반대로 어떤 병목으로 인해 지연시간이 증가하게 되면 시간 당 I/O 회수가 적어지므로 성능이 저하됩니다. 즉 fsr 엔진의 성능을 최적화하려면 이 지연시간이 최소화 되도록 fsr 의 구성 조건들을 조정해서 동작시켜야 합니다.

다음에 설명하는 지연 요소들을 fsr 의 성능모니터를 사용하여 실시간 추적하여 병목이 발생하는 요인들을 확인한 후 그에 맞는 적당한 대응방안을 적용해야 합니다.

시스템 지연

fsr 엔진의 지연요소를 확인하기에 앞서 시스템 자체의 지연시간이 어느 정도인지 파악합니다. 이를 파악하려면 복제를 구성하지 않은 볼륨의 순수한 I/O 성능을 확인해야 합니다. 스토리지의 성능에 따라 다르지만 통상 4KB 단위 I/O를 수행했을 때의 지연시간은 수 nano sec 수준이면 적당한 수치의 성능이라고 보면 됩니다. 이 보다 높게 측정된다면 시스템 자체의 지연이 있는 상태이며  스토리지 자체의 성능을 점검해 볼 필요가 있습니다.

fsr 엔진 지연

다음의 요소들은 fsr 엔진에서 구현하는 구성요소들이며 성능 모니터를 통해 각 요소들 구간의 지연시간을 추적할 수 있습니다.

경로필터

fsr 로 I/O 가 유입되면 fsr 엔진은 경로필터 로직을 수행하여 I/O 의 경로가 리소스 내의 경로인지 즉 복제 대상 I/O 인지를 식별합니다. 이 과정에서 발생하는 지연시간은 fsr에 등록된 복제 대상 경로가 많아질 수록 증가합니다. 따라서 리소스의 복제 대상 경로의 수를 되도록 이면 적게 유지하는 게 바람직합니다. 예를 들어, 개별 파일로 복제 대상을 지정하기 보다는 복제 대상의 최상위 디렉터리 경로로 지정하는게 관리하기도 좋고 성능에도 좋습니다.

제외필터

경로필터와 더불어 사용하는 제외필터의 개수가 많아질 수록 성능에 좋지 않습니다. 되도록이면 제외필터의 개수가 적게 유지되도록 구성하십시오.

로컬 I/O

fsr은 복제 데이터를 버퍼링하기 전에 로컬 쓰기를 먼저 수행합니다. 이 때 로컬 쓰기 I/O 는 위에서 설명한 시스템 지연 시간과 이론적으로 동일한 성능 이어야 합니다. 만약 시스템 지연시간과 차이를 보인다면 이는 어딘가에 문제가 있다는 것을 의미 합니다. 이것은 대부분 fsr 엔진 내부의 병목 문제일 수 있습니다.

송신 버퍼링

로컬 쓰기 I/O 가 완료된 후 복제 데이터를 버퍼로 큐잉하고 원본 I/O를 완료합니다. 버퍼링이 빨리 되어서 원본 I/O 가 즉시 완료된다면 성능이 좋겠지만 버퍼링에 시간이 걸린다면 그 만큼 병목이 발생하고 I/O 가 지연됩니다.

이 때 사용하는 버퍼는 메모리 버퍼와 파일버퍼로 제공 되며 메모리 버퍼는 성능이 높기 때문에 별로 문제가 되지 않지만 파일버퍼는 실제 파일을 버퍼로 삼기 때문에 파일 I/O 가 기존에 비해 두 배로 발생하고 이 병목에 따른 성능저하가 발생합니다. 성능을 고려하면 메모리버퍼를 많이 사용하는게 좋지만 시스템의 자원 상황에 따라 파일버퍼를 같이 운영해야 할 경우라면 이러한 성능저하는 감안하고 사용해야 합니다.

전송 지연

로컬 I/O 는 버퍼링이 되는 시점에 완료가 되므로 버퍼링된 이후의 구간은 로컬 I/O 지연과는 무관합니다. 버퍼링된 데이터가 TX 로 빠져나가는 데 걸리는 데 드는 전송지연은 버퍼링 성능 측면의 지표입니다. 이 성능이 좋아야(전송지연이 낮아야) 복제가 원할하며 만약 버퍼링에 병목이 있다면 fsr 은 버퍼 넘침이 빈번하게 발생되면서 복제 상태를 유지하지 못하고 동기화를 반복하게 됩니다. 버퍼링 성능이 좋지 못한 경우는 fsr 내부 병목의 문제일 가능성이 높습니다.

물론 이것은 네트워크 전송대역이 감당할 수 있는 범위에 한정한 얘기입니다. 만약 로컬 I/O 대역에 비해 네트워크 전송대역이 많이 낮아서 전송대역이 받쳐주지 못하는 상황이라면 대역폭을 더 늘리거나 로컬 I/O 의 분배를 고려해야 합니다.

처리량

단위 시간 당 전송할 수 있는 데이터 양을 처리량으로 정의하며 실시간 복제를 유지하기 위해서는 적어도 로컬 I/O 부하보다 FSR 의 처리량 성능이 좋아야 합니다. 만약 로컬 I/O 부하에 비해 복제 처리량이 낮으면 버퍼 넘침이 유발되어 재동기화 상태가 반복되는 등 복제 상태가 유지되지 못할 수 있습니다. 이를 위해 다음의 내용들이 충족될 수 있도록 고려해야 합니다.

하드웨어

허드웨어의 사양이 높을 수록 처리량은 좋아집니다. 기본적으로 CPU, 메모리, 하드디스크 등 좋은 성능의 I/O 서브시스템을 갖추어야 하며 FSR에는 송신버퍼링을 위한 메모리 자원을 충분히 할당하는 것이 좋습니다.

네트워크 대역

네트워크 전송대역의 한계로 인해 처리량은 네트워크 전송대역 내에서 처리됩니다. 따라서 전송 대역을 최대한 크게 확보하는 게 유리하지만 적어도 로컬에서 발생하는 쓰기 I/O 의 부하량을 미리 파악하고 복제 대역을 미리 추산하여 네트워크 대역을 산정하는 것이 일반적 입니다. 복제 대역을 산정 하려면 로컬 시스템의 쓰기 I/O 에 대한 모니터링을 수행해야 합니다. 예를 들어 로컬 시스템의 평균 쓰기 I/O 가 200MB/s 라고 하면 복제를 위해서 적어도 10Gbps 네트워크 망이 구축되어야 합니다. 

압축

복제 데이터를 압축하여 전송하면 처리량을 개선할 수 있습니다. 데이터 크기를 압축하여 전송에 따르는 소요시간을 줄이는 것은 처리량을 개선하는 가장 고전적인 접근 방법입니다. 다만 소프트웨어적인 압축은 CPU 의 사용량을 점유하기 때문에 로컬에서의 압축은 시스템에 일정 수준의 부하가 발생할 수 있으므로 이를 감안해야 합니다. fsr의 압축 알고리즘은 가장 빠른 압축성능을 제공하는 LZ4 입니다The optimization of FSR is described in terms of both latency of local I/O and throughput of replication traffic.

Latency

The time taken to complete after local I/O is issued and written to disk is called response time or latency.The lower the delay time, the higher the number of I/Os and the better the performance.Conversely, if the latency increases due to a bottleneck, the number of I/Os per hour decreases, resulting in poor performance.In other words, in order to optimize the performance of the fsr engine, it is necessary to adjust the configuration conditions of fsr to minimize this delay time.

The delay factors described below should be tracked in real time using the performance monitor of fsr to check the factors causing bottlenecks and then apply appropriate countermeasures.

System Delay

Before checking the delay factor of the fsr engine, determine how long the delay time of the system itself is.To figure this out, you need to look at the pure I/O performance of the volume without any replication configured.It depends on the performance of the storage, but the latency when performing 4KB I/O is usually a few nanoseconds.If it is measured higher than this, there is a delay in the system itself, and it is necessary to check the performance of the storage itself.

FSR Engine Delay

The following elements are the components implemented in the fsr engine, and the delay time of each element section can be tracked through the performance monitor.

Path Filter

When I/O flows into fsr, the fsr engine performs path filter logic to identify whether the path of the I/O is a path within the resource, i.e., the I/O to be replicated.The delay incurred in this process increases as the number of destination paths registered in fsr increases.Therefore, it is advisable to keep the number of replication target paths for a resource as small as possible.For example, rather than specifying the replication target as an individual file, it is good for management and performance to specify the path to the top-level directory of the replication target.

Exclusion filter 

The higher the number of exclude filters used with the path filter, the worse the performance.If possible, configure the number of exclusion filters to be kept as small as possible.

Local I/O

fsr performs local writes first before buffering the duplicate data.At this point, the local write I/O should theoretically have the same performance as the system latency described above.If there is a difference with the system latency, it means there is a problem somewhere.This can mostly be a bottleneck problem inside the fsr engine.

Tx Bufferring

After the local write I/O is complete, the duplicate data is queued into a buffer and the original I/O is completed.If the buffering is fast and the original I/O is completed immediately, the performance is good, but if buffering takes time, the bottleneck will occur and the I/O will be delayed.

The buffer used at this time is provided as a memory buffer and a file buffer, and it is not a problem because the memory buffer has high performance.There is a decrease in performance due toConsidering the performance, it is better to use a lot of memory buffers, but if you need to operate the file buffers together according to the resource situation of the system, you should consider this performance degradation.

Transmission delay

Local I/O is completed at the time of buffering, so the section after buffering is independent of local I/O delay.The transmission delay it takes for buffered data to exit the TX is an indicator of buffering performance.If this performance is good (low transmission delay), replication is smooth. If there is a bottleneck in buffering, fsr cannot maintain the replication state due to frequent buffer overflow and repeat synchronization.Poor buffering performance is most likely a problem with fsr internal bottlenecks.

So far, this is limited to the range that the network transmission bandwidth can handle.If the network transmission band is very low compared to the local I/O band and the transmission band cannot support it, increase the bandwidth or consider the distribution of local I/O.

Throughput

Throughput defines the amount of data that can be transferred per unit of time, and in order to maintain real-time replication, the throughput performance of the FSR must at least be better than the local I/O load.If the replication throughput is low compared to the local I/O load, buffer overflow may occur and the replication state may not be maintained, such as resynchronization repeating.To do this, it is necessary to consider the following to ensure that:

Hardware

The higher the specification of the hardware, the better the throughput.Basically, you need to have a good performance I/O subsystem such as CPU, memory, and hard disk, and it is recommended to allocate enough memory resources for sending buffering to FSR.

Network Bandwidth

Due to the limitations of the network transmission band, the throughput is handled within the network transmission band.Therefore, it is advantageous to secure the transmission bandwidth as large as possible, but it is common to calculate the network bandwidth by grasping the load of write I/O occurring locally at least and estimating the replication bandwidth in advance.To estimate the replication bandwidth, you need to monitor the write I/O of the local system.For example, if the average write I/O of the local system is 200MB/s, at least a 10Gbps network must be established for replication.

Compression

fsr can improve throughput by compressing and sending replication data.Compressing the size of the data to reduce the transfer time is the most classic approach to improving throughput.However, because software compression occupies CPU usage, local compression may cause a certain level of load on the system, so you should consider this.The compression algorithm of fsr is LZ4, which provides the fastest compression performance.