10시스템 최적화System Optimization in Maestro

Auto-Scaling이란

Maestro Auto-Scaling 은 특정 조건이 충족되면 가용 Security Appliance(Scale Unit)를 Security Group에 자동으로 배정 하는 기능입니다. 어떤 조건에서 어플라이언스를 붙일지(또는 뗄지)는 Quantum Maestro Orchestrator 에서 Security Group별로 구성합니다.

사전 요건

Auto-Scaling을 쓰기 전에 다음 세 가지를 갖춰야 합니다.

  set cluster configuration image auto-clone state on
  show cluster configuration image auto-clone state
  

제한 사항

Auto-Scaling 용어

Auto-Scaling 구성

Auto-Scaling은 Orchestrator에서 Gaia Portal 또는 Gaia Clish 로 구성합니다.

Gaia Portal에서 구성

Gaia Clish에서 구성

   add maestro auto-scale security-group-id <Security Group ID>
   scale-up-policy when {Each-Member | Security-Group-Average}
   with {CPU | bps | pps | connections} more-than <Threshold>
   period <Duration>
   

   set maestro auto-scale security-group-id <Security Group ID>
   scale-units-to-attach <1-4>
   

   add maestro auto-scale security-group id <Security Group ID>
   scale-down-policy when <Security-Group-Average> with {CPU |
   bps | pps | connections} less-than <Threshold> period
   <Duration>
   

   set maestro auto-scale security-group-id <Security Group ID>
   state enable
   

   set maestro auto-scale site-id <Site ID> scale-unit-serial
   <Serial Number> state on
   

Gaia Clish에서 쓰는 관련 명령은 다음과 같습니다.

add maestro auto-scale
set maestro auto-scale
show maestro auto-scale
delete maestro auto-scale

Orchestrator에서 Auto-Scaling 모니터링

아래 작업은 모두 Orchestrator의 명령줄에 접속해 Gaia Clish에 로그인한 뒤 실행합니다.

  show maestro auto-scale security-group-id <Security Group ID> state
  

  show maestro auto-scale scale-units
  

  show maestro auto-scale security-group-id <Security Group ID> scale-up-rules
  

  show maestro auto-scale security-group-id <Security Group ID> scale-down-rules
  

현재 Security Group들과 KPI를 보려면, Gaia Clish에서는 show maestro auto-scale interactive-status 를, Expert mode에서는 mas_cli --interactive 를 실행합니다.

Security Group: 1
Site: 1
Average:
| CPU Utilization: 9%
| Pckt/s: 8
| Bytes/s: 5652
| Connections: 384
Average (w/o 1 SU): | CPU Utilization: 13%
| Pckt/s: 13
| Bytes/s: 8478
| Connections: 576
Member: 1
| CPU Utilization: 7%
| Pckt/s: 12
| Bytes/s: 8562
| Connections: 372
Member: 2
| CPU Utilization: 9%
| Pckt/s: 4
| Bytes/s: 2656
| Connections: 412
[Scale Unit]
Member: 3
| CPU Utilization: 11%
| Pckt/s: 10
| Bytes/s: 5739
| Connections: 369
[Scale Unit]
----------------------------------------------------------------

현재 Auto-Scaling 규칙을 보려면, Gaia Clish에서는 show maestro auto-scale interactive-rules 를, Expert mode에서는 mas_cli --interactive-rules 를 실행합니다.

Security Group: 1
Scale Up Rules:
ID 1: When Each member with CPU utilization exceeds 70% For
60 seconds | No Match
Scale Down Rules:
ID 1: When Security Group with CPU utilization less than 30%
For 60 seconds | Match for 16 seconds
----------------------------------------------------------------

Auto-Scaling 문제 해결

Auto-Scaling 서비스 — 문제를 풀 때는 먼저 masd 서비스가 Orchestrator와 Security Group 멤버 양쪽에서 실행 중 인지 확인합니다. 두 곳 모두에서 Expert mode로 로그인한 뒤 service masd status 를 실행하면, 정상이라면 masd is running... 이 나와야 합니다.

service masd status

Auto-Scaling 로그 파일 — Orchestrator와 Security Group 멤버에서 masd 데몬 로그를 실시간으로 살펴봅니다(각각 Expert mode).

tail -F /var/log/masd.elg

Auto-Scaling 규칙 확인 — Orchestrator에서 구성한 규칙이 제대로 적용됐는지 보려면, Expert mode에서 mas_cli --interactive-rules 로 규칙 목록을 받아 Gaia Portal/Clish에서 구성한 내용과 비교 합니다.

멤버의 KPI 보고 확인 — Security Group 멤버가 Orchestrator로 KPI를 제대로 보고하는지 보려면, Orchestrator의 Expert mode에서 mas_cli --interactive 로 KPI 상태를 확인합니다.

Fastforward란

Maestro Fastforward 는 신뢰하는 연결에 대해 선택한 정책 규칙을 Quantum Maestro Orchestrator로 오프로드해, accept/drop을 하드웨어 수준에서 가속 하는 기능입니다.

주요 이점은 다음과 같습니다.

그림: Fastforward 동작 개요 (p.234)

Fastforward의 동작 원리

정책(Policy) — 관리자는 오프로드하려는 규칙의 이름에 특정 접두사(prefix, 변경 가능) 를 붙여 표시합니다. 정책 설치 시, 해당 규칙들은 ACL(Access Control List) 로 변환되어 Orchestrator로 오프로드되고 하드웨어 수준에서 적용됩니다.

라우팅(Routing) — Layer 3(라우팅) 수준에서 신뢰 연결을 가속하려면, Orchestrator가 Security Gateway와 동일한 토폴로지 시각 을 가져야 올바른 출력 인터페이스와 next hop으로 패킷을 보낼 수 있습니다. 따라서 이 기능은 Security Gateway/Virtual System의 라우팅 토폴로지를 복제하며, 이 로직은 하드웨어 수준에서 일어나 매우 견고합니다.

Fastforward FAQ

지원되는 배포 유형은?

Fastforward로 가속된 연결도 방화벽 로깅이 되나?

Client→Server, Server→Client(리턴 트래픽) 규칙을 따로 추가해야 하나?

아니요. stateful inspection처럼 규칙을 만들면 됩니다. ACL 변환 메커니즘이 C2S/S2C 규칙을 자동으로 추가 합니다.

방화벽이 Fastforward 가속 트래픽을 검사하나?

(Accept 규칙의) SYN / SYN-ACK 패킷만 검사합니다. 신뢰 연결을 Orchestrator 하드웨어 수준으로 완전히 오프로드하는 것이 이 기능의 맞교환이며, 그 덕에 Security Group 멤버에 영향 없이 매우 낮은 지연과 높은 처리량을 얻습니다.

Fastforward 토폴로지

Fastforward 구성

이 기능은 기본적으로 꺼져 있습니다. Security Group마다 구성하며, VSX 모드에서는 Virtual System마다 구성합니다.

Fastforward 켜기

1/2단계 — Security Group에서 구성

   set virtual-system <VSID>
   

   set maestro fastforward rulebase-prefix enable prefix <Name Prefix>
   

예를 들어 접두사를 ff_rule 로 설정했다면, 정책 규칙 이름은 ff_rule_1, ff_rule_2 처럼 짓습니다.

   [Global] MyChassis-01> set maestro fastforward rulebase-prefix enable prefix ff_rule
   1_01:
   Fastforward prefix status: enabled. Prefix is "ff_rule"
   Please install policy from SmartConsole for the change to take effect.
   2_01:
   Fastforward prefix status: enabled. Prefix is "ff_rule"
   Please install policy from SmartConsole for the change to take effect.
   

   set maestro fastforward state on
   

출력 예:

   Routing configuration validation finished successfully.
   Fastforward status: enabled
   Please install policy from SmartConsole for the change to take effect.
   2_01:
   Routing configuration validation finished successfully.
   Fastforward status: enabled
   Please install policy from SmartConsole for the change to take effect.
   

2/2단계 — SmartConsole에서 구성

예: 이름 ff_rule_1, Source Backup_Server_1, Destination Backup_Server_2, Services nfsd-tcp, Action Accept, Track Log, Install On Policy Targets.

Fastforward용 Access Control 규칙에 대한 추가 주의 사항은 다음과 같습니다.

Action "Accept" 규칙에 대한 주의 사항

Action "Drop" 규칙에 대한 주의 사항

Fastforward 끄기

1/2단계 — Security Group에서 구성

   set maestro fastforward state off
   

이 작업이 실패하면 강제로 끌 수도 있습니다("Fastforward 문제 해결" 참고). 출력 예:

   clearing ACLs from all relevant Orchestrators
   Fastforward status: disabled
   2_01:
   clearing ACLs from all relevant Orchestrators
   Fastforward status: disabled
   

2/2단계 — SmartConsole에서 구성

Fastforward 모니터링

Security Group은 평소처럼 TCP 연결을 로깅하므로 SmartConsole/SmartView에서 로그를 볼 수 있고, Orchestrator의 tor_util fastforward 명령으로 추가 정보를 얻습니다.

Fastforward 규칙의 hit 보기 — Orchestrator에 접속해 Expert mode로 로그인한 뒤 실행합니다.

tor_util fastforward show rules <Security Group ID> {0 | <Virtual System ID>}

Gateway 모드에서 Security Group 1의 출력 예:

[Expert@MHO1:0]# tor_util fastforward show rules 1 0
Fastforward Rule Hits:
======================
| Counter ID | Hit Count | Port       | Direction | Description
| 66240512   | 472065    | FF_SG1_VS0 | inbound   | Rule 1 C2S UDP, 1.1.1.0/24:ANY -> 2.2.2.0/24:3000, ACCEPT
| 66256896   | 23740853  | FF_SG1_VS0 | inbound   | Rule 1 S2C UDP, 2.2.2.0/24:3000 -> 1.1.1.0/24:ANY, ACCEPT
| 66273280   | 102381    | FF_SG1_VS0 | inbound   | Rule 2 C2S UDP, 1.1.1.0/24:ANY -> 2.2.2.0/24:4000, DROP
| 66289664   | 589884    | FF_SG1_VS0 | inbound   | Rule 3 C2S TCP, 10.10.10.0/24:ANY -> 20.20.20.0/24:22, ACCEPT
| 66306048   | 968405    | FF_SG1_VS0 | inbound   | Rule 3 S2C TCP, 20.20.20.0/24:22 -> 10.10.10.0/24:ANY, ACCEPT
| 66322432   | 0         | FF_SG1_VS0 | inbound   | Rule 4 C2S UDP, 10.10.10.0/24:ANY -> 20.20.20.0/24:445, ACCEPT
| 66338816   | 0         | FF_SG1_VS0 | inbound   | Rule 4 S2C UDP, 20.20.20.0/24:445 -> 10.10.10.0/24:ANY, ACCEPT
| 66371584   | 0         | FF_SG1_VS0 | inbound   | Rule 5 C2S ip proto ANY, 9.9.9.9/32:ANY -> 10.10.10.10/32:ANY, ACCEPT
| 66027520   | 0         | FF_SG1_VS0 | inbound   | Rule 5 S2C ip proto ANY, 10.10.10.10/32:ANY -> 9.9.9.9/32:ANY, ACCEPT

현재 구성 상태 보기 — Orchestrator의 Expert mode에서 실행합니다.

tor_util fastforward show status <Security Group ID> {0 | <Virtual System ID>} [verbose]

관리자를 위한 Fastforward 고려 사항

Fastforward의 라우팅 메커니즘

정책 설치 동안 Security Group은 다음 네트워킹 정보로 Orchestrator를 갱신합니다.

Orchestrator는 이 정보로 자신의 하드웨어 안에 토폴로지를 구성 합니다. Orchestrator가 둘이면 각자 자신에게 있는 인터페이스를 기준으로 자기 토폴로지를 만듭니다. 예컨대 종속 인터페이스가 eth1-01, eth2-01 인 bond1 이 토폴로지에 있다면, Orchestrator #1은 eth1-01 을, Orchestrator #2는 eth2-01 을 자기 토폴로지에 둡니다. 각 Orchestrator는 로컬에서 가속하며 Orchestrator 간 전달이 없기 때문입니다.

가속 대상 Access Control 규칙에 패킷이 매칭되면, 라우팅 메커니즘으로 넘어가 라우팅 결정을 내리고, 그 결정에 따라 패킷을 내보낼 출력 인터페이스를 찾습니다. 라우팅 토폴로지를 보려면 Orchestrator의 Expert mode에서 실행합니다.

tor_util fastforward show status <Security Group ID> {0 | <Virtual System ID>} verbose

Fastforward의 정책 메커니즘

가속할 신뢰 흐름의 정책 규칙은 규칙 이름의 고유 접두사 로 정의합니다. 정책 설치 동안 Management Server가 이 규칙들을 stateless ACL로 변환해 Security Group으로 전달하고, Security Group이 다시 Orchestrator로 전달해 적용합니다.

가속 연결은 방화벽 보안 기능을 우회해 높은 처리량과 낮은 지연을 얻으므로 반드시 신뢰할 수 있는 연결 이어야 합니다.

이 가속은 SecureXL처럼 연결/세션마다가 아니라 오프로드된 ACL(규칙)마다 적용되는 stateless 가속 입니다. 오프로드된 규칙을 보려면 Expert mode에서 tor_util fastforward show status <Security Group ID> {0 | <Virtual System ID>} 를 실행합니다(출력은 "Fastforward 모니터링"의 예와 같은 형식).

SMO의 정책 설치 흐름

SMO의 라우팅 처리 — (1) "Check": 새 라우팅 토폴로지 변경이 있는지 확인, (2) "Apply": 변경을 Orchestrator에 적용.

정책 처리 —

패킷 매칭 —

매칭과 무관하게 일부 패킷은 항상 Security Group으로 보냅니다 — (Accept 규칙의) TCP SYN·SYN-ACK 패킷 과 (사용자 정의 서비스 규칙의) 단편화(fragmented) 패킷 입니다.

Fastforward 특별 고려 사항

같은 사이트에 Orchestrator가 여러 대일 때

Cross-bond 요건 — 각 Orchestrator는 자기만의 가상 라우팅 토폴로지를 만들고 Orchestrator 간 전달이 없으므로, 인터페이스를 반드시 cross-Orchestrator bond 인터페이스 로 구성해야 합니다. 즉 각 bond가 Orchestrator마다 종속 인터페이스를 가져야 합니다.

종속 인터페이스 모니터링 — 한쪽 Orchestrator만 종속 인터페이스의 링크를 잃으면, 한쪽 Orchestrator와 Security Group은 완전한 토폴로지를 갖지만 다른 Orchestrator는 종속 인터페이스를 잃어 로컬 가속을 못 하게 되어 라우팅이 일관되지 않게 됩니다. 이때 두 Orchestrator는 임시 bypass 상태 로 들어가 트래픽을 Security Group으로 보내고, 링크가 "up"으로 돌아오면 임시 bypass에서 빠져나옵니다.

토폴로지 불일치(Topology inconsistency) — 같은 사이트에 Orchestrator가 여러 대인 배포에서 일어날 수 있습니다. 각 Orchestrator가 로컬에서 가속하므로 모든 인터페이스를 cross-Orchestrator bond로 구성 해야 각 Orchestrator가 전체 토폴로지를 보고 내부적으로 가속을 완성할 수 있습니다. 한쪽 Orchestrator에서만 bond 링크가 실패하면 트래픽 손실이나 잘못된 라우팅이 생길 수 있고, 이때 현재 사이트의 Orchestrator들은 internal bypass 라는 특수 모드로 들어갑니다. 토폴로지가 다시 일관되면 internal bypass에서 나와 마지막 원하던 상태(active/inactive)로 돌아갑니다.

예 — Orchestrator 두 대와 bond 두 개(Bond1 외부, Bond2 내부)인 배포로, 각 bond는 Orchestrator마다 두 개씩 총 네 개의 종속 인터페이스를 가집니다.

bond1이 완전히 실패하면 토폴로지는 일관성을 유지합니다. 하지만 bond1에서 eth2-05, eth2-06 만 실패하면 Orchestrator2는 bond1 토폴로지가 불일치하고, Orchestrator1과 Security Group은 여전히 일관됩니다. 이 경우 Orchestrator들은 불일치를 감지해 internal_bypass 모드로 들어가고, 불일치가 해소될 때까지 모든 트래픽이 Security Group으로 흐릅니다.

Dual Site

Fastforward는 활성 사이트에서만 트래픽을 가속 하고 standby 사이트는 비활성 상태입니다. 사이트 절체가 일어나면 새 SMO가 Orchestrator들을 새 상태로 갱신해 각각 활성/비활성화합니다.

다운링크 포트 모니터링

Fastforward는 각 Orchestrator에 연결된 다운링크 포트의 링크 상태를 모니터링합니다. 한 Orchestrator의 모든 다운링크 포트가 실패하면 기본적으로 그 Orchestrator에서 bypass 모드로 들어가, Security Group에 멤버가 없을 때 트래픽이 전달되지 않게 합니다.

Bond 인터페이스 지원

한 Orchestrator에 여러 bond 종속 인터페이스가 있으면(예: bond1에 eth1-01, eth1-02), Orchestrator는 트래픽을 보낼 기본(primary) 종속 인터페이스 를 고릅니다. bond 인터페이스가 Orchestrator가 아니라 Security Group 멤버에만 구성되기 때문입니다. 이를 보완하는 방식은 다음과 같습니다.

Fastforward의 알려진 제한 사항

일반(General)

PMTR-108476 단기 우회책 절차:

Layer 3

Security Group

Topology

Layer 2

Fastforward 문제 해결

트래픽 흐름 추적 — Orchestrator에서 규칙의 hit count가 증가하는지 확인합니다. TCP 연결은 tcpdump 명령으로 트래픽을 캡처하거나 SmartConsole 로그를 살핍니다.

즉석에서 우회(bypass)·재개하기 — 문제 해결의 일환으로 Fastforward를 끄지 않고 우회 할 수 있습니다. 우회하면 트래픽이 Fastforward 오프로드 규칙 매칭을 건너뛰고 해당 Security Group으로 갑니다.

   member {ssm1 | ssm2}
   

     tor_util fastforward policy operation_mode <Security Group ID> {0 | <Virtual System ID>} bypass
     

     tor_util fastforward policy operation_mode <Security Group ID> {0 | <Virtual System ID>} skip_bypass
     

출력 예:

[Expert@MHO1:0]# tor_util fastforward policy operation_mode 1 0 bypass
operation mode was set successfully
[Expert@MHO1:0]# tor_util fastforward policy operation_mode 1 0 skip_bypass
operation mode was set successfully
It is required to install policy in order for the change to take effect.

정책 실패 문제 해결 — 다음 파일들을 살핍니다.

SMO Security Group 멤버에서:

Orchestrator에서:

강제로 Fastforward 끄기 — 끄기 작업이 실패하면 강제로 끌 수 있습니다.

   g_all "/usr/scripts/acl_cli/acl_cli fastforward disable --force"
   

   orchd restart
   

Security Group의 각 멤버에 있는 로깅 메커니즘은 이 Security Group에 배정된 Orchestrator 관리 포트 를 통해 로그를 전용 Log Server로 직접 보냅니다. 그런데 멤버들이 많은 로그를 생성하면 Orchestrator 관리 포트에 높은 부하 가 걸릴 수 있습니다. 이를 줄이려면 (1) Security Group에 로깅용 management 유형의 전용 Orchestrator 포트를 배정하고, (2) Security Group이 전용 Log Server로 로그를 보내도록 구성합니다.

토폴로지:

[Management Server](some interface) <===> (management port 1 on Quantum Maestro Orchestrator)[Security Group]
[Management Server](some interface) <===> (interface 1) [Log Server]
(interface 2) <===> (management port 2 on Quantum Maestro Orchestrator)[Security Group]

절차:

3단계 구문:

[Expert@HostName-ch0x-0x:0]# gclish
[Global] HostName-ch01-01> set interface ethX-MgmtY ipv4-address <IPv4 Address> mask-length <Mask Length>

예:

[Global] HostName-ch01-01 > set interface eth1-Mgmt2 ipv4-address 2.2.2.10 mask-length 24

Security Group 가중치(고가용성 계수) 설정

Security Group 멤버의 각 하드웨어 구성 요소에는 Security Group 전체 건강 상태에 대한 상대적 중요도 를 정하는 품질 가중치(quality weight factor)가 있습니다. 예컨대 포트는 다른 구성 요소보다 중요해 보통 더 높은 가중치를 받습니다.

멤버의 등급(grade)은 모든 구성 요소 가중치 값의 합이며, Dual Site 환경에서는 등급이 더 높은 Security Group이 Active 가 되어 트래픽을 처리합니다. 각 구성 요소의 등급은 다음 공식으로 계산합니다.

(Unit Weight) x (Number of components in the state "UP")

각 구성 요소의 가중치를 보려면 Security Group의 Gaia gClish에서 asg stat -v 를 실행합니다.

하드웨어 구성 요소의 가중치는 set cluster configuration high-availability factors 명령으로 구성합니다. Security Group의 Gaia gClish 구문은 다음과 같습니다.

set cluster configuration high-availability factors member <Security Group Factor>
set cluster configuration high-availability factor {other <Other Port Factor> | standard <Standard Port Factor> | mgmt <Management Port Factor> | bond <Bond Port Factor>}

자세한 내용은 명령줄 레퍼런스의 show cluster configuration high-availability, set cluster configuration high-availability 항목을 참고하세요.

예:

[Global] HostName-ch01-01 > set cluster configuration high-availability factors sgm 100
[Global] HostName-ch01-01 > set cluster configuration high-availability factors port other 70
[Global] HostName-ch01-01 > set cluster configuration high-availability factors port standard 50

품질 등급 차이(Differential) 설정

set cluster configuration high-availability failover 명령으로 절체(failover)를 일으키는 최소 품질 등급 차이 를 구성합니다. Security Group의 Gaia gClish 구문은 다음과 같습니다.

set cluster configuration high-availability failover <Trigger>

Maestro에서 신원 기반 접근 제어(Identity Based Access Control)와 Threat Prevention 을 구성하는 설계 지침은 sk175587 을 참고하세요.