Failover link, stateful link

failover에서 필요한 link 두 가지 failoverlink, stateful link

 

저번 시간에 배웠던 failover와 failover의 구조인 active-standby, active-active 구조를 지나서

이제 failover가 발생할 때 중요한 역할을 하는 두 가지 link에 대해서 배워보도록 할게

 

 

 

 

failover link

failover pair가 된 두 unit 사이에서 unit끼리 지속적으로 각자의 상태를 결정을 해야 하는데

이때 사용하는 link가 failover link야 failover link에서는 다음과 같은 data들을 송수신해

 

 

- unit state (active인지 standby인지 상태 확인)

- hello messsage (unit이 살아있는지 죽어있는지 확인)

- network link status

- mac address exchange (failover 발생 시, MAC 주소를 standby로 보낼 때)

- config replication & sync (config 복제 및 동기화 작업)

 

 

위의 data들을 보면 알 수 있듯이 failover link는 networking을 목적으로 하는 link가 아님을 알 수 있어

그리고 failover를 사용할 때는 failover를 대체할 수 있는 또 다른 interface를 만들어 놓는 것이 이중화 작업에 있어서 효율적이야

만약, 기존에 쓰던 failover link가 shutdown 되었을 경우에 서로 hello message를 주고받을 수 없게 되었다면,

이를 대체할 수 있는 다른 interface를 통해서 failover link의 역할을 수행할 수 있도록 이중화 구성을 하는 것이 좋아!

 

 

 

 

stateful link

stateful link는 두 unit 간에 connection 상태 정보를 송수신하기 위해 사용하는 link야

stateful link가 설정된다면 active unit은 지속적으로 standby unit에게 connection 정보를 전송하게 돼

결론적으로 stateful link를 사용하게 되면 새롭게 올라간 active unit에도 기존의 connection 정보를 쓸 수 있어

stateful link 없이 user들이 service를 사용하고 있던 와중에

만약 web service가 failover 발생으로 끊겼다면 어떻게 될까?

web service를 다시 사용하려고 새로운 active unit과 3-way handshaking으로 session을 다시 맺고

http request와 http response를 서로 다시 주고받아야 web service를 사용하겠지..?

이런 불편함을 줄일 수 있도록 stateful link가 failover 발생 후에도

기존에 사용하던 active 장비에서 session 정보들을 그대로 새로운 active unit에게 전송해주는 거야

그러면 어떤 data들이 들어가 있는지 확인해보도록 할게

 

 

- NAT translation table (사설, 공인 IP 간의 주소변환 session 정보)

- TCP/UDP connection table (위에 예시를 보면 알겠지?)

- HTTP connection table (단, http relication enable을 설정했을 때만 가능, default는 안됨)

- ARP table (해당 unit이 가지고 있던 arp table 정보 -> MAC 주소와 IP 주소 간의 mapping 정보)

 

 

 

failover polltime & holdtime

 

ASA failover에서 monitoring 할 요소인 unit과 interface에 대해 알아볼게

 

 

1. unit 상태 확인

ASA 방화벽은 상대 unit의 상태를 확인하기 위해 failover link에서 hello message를 상대에게 보내고,

이에 대한 응답에 따라 상대 unit의 상태를 결과적으로 파악하게 돼

이때, unit이 failover link로 hello message를 3번 연속받지 못할 경우,

unit은 data interface 뿐만 아니라 failover link에도 상대 unit이 응답 여부를 검증을 하기 위해

LANTEST message를 전송해

이제, 상대 unit에게서 failover link로 응답된 결과에 따라 failover 발생 여부가 달라질 거야. 어떤 경우가 나오는지 살펴보자면...!

 

 

- unit이 failover link를 통해서 상대로부터 hello 응답을 받았다면 failover 발생하지 않음

- unit이 failover link를 통해 hello 응답을 받지 못했지만, data interface를 통해서 응답을 받았을 경우에도 failover를 실행하지 않아

failover link는 failed marking이 되지만, failover link를 빠르게 복구시켜 failover link 기능을 살려놓도록 해야 해

- 만약 unit이 어떠한 interface를 통해서든 hello message를 받지 못하는 상황이면, standby unit은 active unit으로 전환

다른 unit은 failed로 변환되어 active 권한이 standby로 넘어가게 돼

 

 

unit 상태를 monitoring 할 때, hello message 전송 주기를 설정할 수 있어

이때 나오는 개념이 바로 polltime과 holdtime이야

polltime을 줄이는 것은 unit의 상태를 확인하는 데 있어서 더 빠르게 찾을 수 있도록 해줘

하지만, 그만큼 system에 부하가 발생하겠지? 

이렇게 되면, network에 혼잡도가 증가하거나 단순 장애로 인한 문제에 대해서도 이를 fail로 판단을 하게 돼

polltime과 holdtime이 무조건적으로 짧아야 failover 성능이 좋아진다고 볼 수 없겠지?

 

 

명령어: failover polltime [msec] (시간) [holdtime] [msec] (시간)

polltime = unit의 상태를 확인하는 데 걸리는 시간 결정

holdtime = hello 패킷이 누락된 시간부터 장애 조치가 발생할 때까지 걸리는 시간 결정

 

polltime 주기는 1~15초로 설정할 수 있고, msec option을 설정하면 200~999ms까지도 설정 가능해

holdtime의 경우 주기를 1~45초로 설정할 수 있고, msec option을 설정하면 800~900ms까지도 설정 가능해

 

 

 

 

 

2. interface monitoring

기본적으로 ASA는 1025개의 interface를 monitoring 할 수 있어

network 통신에 있어서 중요한 interface는 꼭 monitoring을 해야 할 필요가 있어!

그래야 interface 간에 어떤 정보가 오고 가고 어떤 문제가 발생했는지 상태를 확인할 수 있으니까

이제 interface monitoring은 어떻게 진행되는지 확인해보도록 할게

interface의 상태를 파악하기 위해 hello pacekt을 각각의 interface에 보내는데,

만약 hello packet을 상대 unit과 연결된 interface로부터 hold time의 절반이 되는 시간 동안 오지 않았다면,

추가적인 interface test를 실행해봐야 해.

test를 진행해도 hold time 내로 hello packet이나 성공한 test 결과를 받지 못했다면

해당 interface는 fail로 처리가 돼

failover는 만약 이 fail이 된 interface들의 수가 failover 정책 기준과 만나게 되면 발생하게 되는 거야

 

명령어: failover interface-policy num [%] -> fail 된 interface의 비율을 임계치로 설정

해당 임계치에 도달하거나 초과될 경우 failover를 발생시키게 돼

 

이때, failover time 기준을 "failover polltime interface" 명령으로 변경시킬 수 있어

poll time과 hold time을 줄여서 좀 더 빠르게 interface의 실패 상태에 응답하고 차단할 수 있게 돼

이것도 마찬가지로 그만큼 system의 resource를 끌어다 쓰기 때문에 system 부하가 발생할 수 있지

 

명령어: failover polltime interface [msec] time hold time

 

polltime 주기는 1~15초로 설정할 수 있고, msec option을 설정하면 500~999ms까지도 설정 가능해

holdtime 주기는 5~75초로 설정할 수 있고, polltime의 5배 이하로 설정할 수 없어

 

cf) 만약 interface link가 down이 되었다면, interface testing은 실행되지 않고,

fail 된 interface 수가 구성된 failover 기준에 맞거나, 초과된 경우 standby unit에

interface polling 기간 안에 활성화될 수 있어.

 

 

 

 

 

3. interface test

interface test는 세부적으로 살펴보면 default로 약 1.5초 동안 test를 진행하게 되거나

failover interface의 hold time의 1/16초 정도 test를 진행하게 돼

이때, 진행하는 test는 총 네 가지인데 다음과 같아

 

1) link up/down test

interface 상태를 확인하는 test로 interface가 down이 되었을 경우, test를 실행하지 않고, 

interface가 up일 경우, network activity test로 넘어간다.

 

2) network activity test

network 활동상태를 확인하는 test로, 시작에 앞서 각 unit들은 interface를 통하여 받은 packet들을 지워

unit은 test동안 packet들을 받자마자 interface가 정상 운영할 수 있음을 확인해

만약 두 unit들 모두 traffic을 받을 경우, test를 종료하고, 하나의 unit은 traffic을 받고 다른 unit은 못 받았을 경우

해당 unit에 interface는 fail 된 상태로 간주하고 test를 멈추게 돼.

두 unit 모두 traffic을 받지 않는다면, 바로 다음 test인 arp test로 넘어가게 돼

 

3) arp test

arp reply가 성공적으로 test가 되는지 확인하는 과정으로, 만약 unit이 arp reply를 받았다면 

해당 interface는 가동 준비가 된 것이고 두 unit이 모두 arp reply를 받았다면 test를 종료하게 돼

하지만, arp reply를 받지 못했다면, ASA는 arp table에 다음 entry에 있는 arp request를 보내게 돼

여기서 arp reply를 받았다면 해당 interface는 가동 준비가 되었다고 파악할 수 있고

한 unit은 성공했지만, 한 unit의 경우 reply가 오지 않았다면, 해당 unit의 interface를 fail로 간주하고

test를 종료하게 돼

해당 test에서도 unit 둘 다 reply를 받지 못했다면, 다음 단계인 broadcast ping test로 넘어가!

 

4) broadcast ping test

ping에 대한 응답 여부를 확인하는 test로 unit들이 broadcast ping을 보내고 받은 packet들을 모두 계산해

test동안 unit이 어떠한 packet이라도 받으면 가동 준비가 되었다고 판단해

만약, 두 unit 모두 reply를 받았다면 test는 종료돼

한 unit은 받고 다른 unit은 받지 못한 경우에는 받지 못한 unit의 interface를 fail로 간주하고 test를 종료해

만약 unit 둘 다 traffic을 받지 못했다면 test는 다시 arp test로 넘어가게 되고

2번~4번 test를 traffic을 못 받는 기간 동안 무한히 계속 실행하게 돼

 

 

 

 

failover times

위의 내용들을 거쳐서 failover 내부에서 어떤 일들이 일어나는지 확인해봤어

이제 마지막으로 failover는 언제 발생하는지 확인해보고 이번 chapter를 마치도록 할게

 

1. active unit의 snort instance가 50% 이상 down 되었을 경우

2. active unit의 disk 사용량이 90% 이상일 경우

3. active unit에 no failover를 실행하거나 standby unit에서 failover active 명령을 실행한 경우

4. active unit이 standby unit보다 interface fail 상태가 더 많은 경우

5. active 장비에 fail 된 interfacerk 설정한 임계치를 초과한 경우

 

interface가 한 개인 경우, 해당 interface가 fail이 되면 failover는 바로 동작하게 되는데

이를 방지하려면 다른 interface를 통해 failover를 실행할 수 있도록 이중화를 구성하는 것이 좋고

failover interface-policy 명령을 통해 fail 된 interface의 임계치를 측정하여 failover를 조정할 수 있어

 

 

오늘도 여기까지~