데브러너 (DevRunner)

25.2.3 NDB Cluster Hardware, Software, and Networking Requirements

NDB Cluster의 강점 중 하나는, 모든 live data 저장이 메모리에서 이루어진다는 사실 때문에 많은 양의 RAM이 필요하다는 점을 제외하면, 범용 하드웨어에서 실행될 수 있고 이와 관련하여 특별한 요구 사항이 없다는 것입니다. 이 요구사항은 Disk Data 테이블을 사용하여 줄일 수 있습니다. 이에 대한 더 많은 정보는 Section 25.6.11, “NDB Cluster Disk Data Tables”를 참조하십시오. data 노드별 메모리 사용량 정보는 ndbinfo.memoryusage 테이블을 조회하거나 ndb_mgm 클라이언트에서 REPORT MemoryUsage 커맨드의 출력으로부터 얻을 수 있습니다. NDB 테이블이 사용하는 메모리에 대한 정보는 ndbinfo.memory_per_fragment 테이블을 조회하면 됩니다.

data 노드를 호스팅하는 컴퓨터에서 CPU 수를 늘리거나 더 빠른 CPU를 사용하거나, 또는 둘 다를 사용할 경우 일반적으로 NDB Cluster의 성능 향상을 기대할 수 있습니다. data 노드 이외의 클러스터 프로세스에 대한 메모리 요구사항은 상대적으로 작습니다.

NDB Cluster에 대한 소프트웨어 요구사항 또한 크지 않습니다. 호스트 운영 체제는 NDB Cluster를 지원하기 위해 특별한 모듈, 서비스, 애플리케이션, 또는 구성을 필요로 하지 않습니다. 지원되는 운영 체제의 경우, 표준 설치만으로 충분합니다. MySQL 소프트웨어 요구사항은 단순합니다. 필요한 것은 프로덕션 릴리스의 NDB Cluster뿐입니다. NDB Cluster를 사용하기 위해 MySQL을 직접 컴파일해야 하는 것은 엄밀히 말해 필요하지 않습니다. 여기서는 여러분이 플랫폼에 적합한 바이너리를 사용한다고 가정하며, 이는 https://dev.mysql.com/downloads/cluster/ 에 있는 NDB Cluster 소프트웨어 다운로드 페이지에서 구할 수 있습니다.

node 간의 통신을 위해, NDB Cluster는 표준 토폴로지라면 어떤 것이든 TCP/IP 네트워킹을 지원하며, 각 호스트에 대해 최소한으로 기대되는 것은 표준 100 Mbps 이더넷 카드와, 클러스터 전체에 대한 네트워크 연결성을 제공할 스위치, 허브, 또는 라우터입니다.

우리는 NDB Cluster를 클러스터에 속하지 않는 머신과 공유하지 않는 자체 서브넷에서 실행할 것을 강력히 권장합니다. 프라이빗 또는 보호된 네트워크를 사용하면 클러스터 호스트 간의 대역폭을 클러스터가 독점적으로 사용할 수 있습니다. NDB Cluster 설치를 위해 별도의 스위치를 사용하면, 클러스터에 저장된 data에 대한 무단 접근으로부터 보호하는 데 도움이 될 뿐만 아니라, 네트워크에 있는 다른 컴퓨터 간의 전송으로 인해 발생하는 간섭으로부터 클러스터 노드를 보호하는 역할도 합니다. 신뢰성을 강화하기 위해, 네트워크를 single point of failure에서 제거하기 위해 dual 스위치와 dual 카드가 사용될 수 있습니다. 많은 디바이스 드라이버가 이러한 통신 링크에 대한 페일오버를 지원합니다.

NDB는 Section 25.6.19.4, “File System Encryption for NDB Cluster”에서 설명한 것처럼, live 및 backup 파일과 파일 시스템에 대한 암호화를 지원합니다. Section 25.6.19.5, “TLS Link Encryption for NDB Cluster”에서는 node 간 암호화된 커넥션에 대한 지원을 활성화하는 방법에 대한 정보를 제공합니다. 암호화된 backup은 ndb_restore, ndbxfrm, ndb_print_backup_file, ndb_mgm을 포함한 많은 NDB 커맨드라인 프로그램에서 읽을 수 있습니다. 암호화된 backup을 생성하는 방법에 대한 더 많은 정보는 Section 25.6.8.2, “Using The NDB Cluster Management Client to Create a Backup”를 참조하십시오.

NDB Cluster는 또한 node 간의 암호화된 네트워크 커넥션도 지원합니다. 자세한 내용은 Section 25.6.19.4, “File System Encryption for NDB Cluster”를 참조하십시오.

Network communication and latency.

NDB Cluster는 query 및 update를 실행하기 위해 data node와 API node(SQL node 포함) 간, 그리고 data node와 다른 data node 간의 통신을 필요로 합니다. 이러한 프로세스 간의 통신 지연 시간은 사용자 query의 관측되는 성능 및 지연 시간에 직접적인 영향을 줄 수 있습니다.

추가로, node의 silent failure에도 불구하고 일관성과 서비스를 유지하기 위해, NDB Cluster는 heartbeat 및 timeout 메커니즘을 사용하여 node로부터의 통신이 일정 시간 이상 끊어지는 경우 node failure로 간주합니다. 이는 redundancy 감소로 이어질 수 있습니다. node group의 마지막 node가 실패하면 data 일관성을 유지하기 위해 NDB Cluster는 shutdown된다는 점을 상기하십시오. 따라서 강제 shutdown의 위험을 줄이기 위해, node 간 통신 단절은 가능한 한 피해야 합니다.

data node 또는 API node 중 하나가 실패하면, 실패한 node가 관여한 commit되지 않은 모든 트랜잭션이 abort됩니다. data node 복구를 위해서는, 해당 data node가 서비스로 복귀하기 전에, 실패한 node의 data를 살아 있는 data node 중 하나로부터 동기화하고, 디스크 기반 redo 및 체크포인트 로그를 다시 설정해야 합니다. 이 복구에는 일정 시간이 소요될 수 있으며, 그 동안 Cluster는 감소된 redundancy로 동작합니다.

heartbeating은 모든 node에 의해 heartbeat 시그널이 적시에 생성되는 것에 의존합니다. node가 과부하 상태이거나, 다른 프로그램과의 공유로 인해 머신 CPU가 부족하거나, 스와핑으로 인한 지연을 겪고 있는 경우에는 이를 달성하지 못할 수 있습니다. heartbeat 생성이 충분히 지연되면, 다른 node들은 응답이 느린 해당 node를 failed node로 취급합니다.

이렇게 느린 node를 failed node로 취급하는 것이, 해당 node의 느려진 동작이 클러스터의 나머지 부분에 미치는 영향에 따라, 어떤 상황에서는 바람직할 수도 있고 그렇지 않을 수도 있습니다. NDB Cluster에 대해 HeartbeatIntervalDbDb 및 HeartbeatIntervalDbApi와 같은 timeout 값을 설정할 때에는, 빠른 감지, 페일오버, 서비스 복귀를 달성하면서도 비용이 많이 들 수 있는 false positive를 피하도록 주의해야 합니다.

data node 간 통신 지연 시간이 LAN 환경(약 100 µs 수준)에서 기대되는 것보다 높을 것으로 예상되는 경우, 허용되는 지연 시간 기간이 설정된 timeout 내에 충분히 포함되도록 timeout 파라미터를 증가시켜야 합니다. timeout을 이렇게 증가시키면 failure 감지 및 그에 따른 서비스 복구까지의 최악의 소요 시간에 상응하는 영향이 발생합니다.

LAN 환경은 일반적으로 안정적인 저 지연 시간으로 구성할 수 있으며, 빠른 페일오버를 통한 redundancy를 제공할 수 있습니다. 개별 링크 failure는 TCP 수준(NDB Cluster가 일반적으로 동작하는 계층)에서 최소화되고 제어 가능한 지연 시간으로 복구될 수 있습니다.

WAN 환경은 다양한 지연 시간 범위를 제공할 수 있으며, 페일오버 시간이 더 느린 redundancy를 제공할 수 있습니다. 개별 링크 failure는 end-to-end 연결성이 복원되기 전에 라우트 변경이 전파되기를 요구할 수 있습니다. TCP 수준에서는 이것이 개별 채널에서의 큰 지연 시간으로 나타날 수 있습니다. 이러한 시나리오에서 관측되는 최악의 TCP 지연 시간은, failure 주변으로 우회하기 위한 IP 계층의 최악의 reroute 시간과 관련이 있습니다.