검증자 노드
검증자 노드는 합의에 참여하며 감금(jailing)을 피하기 위해 일관된 성능을 유지해야 합니다. 베어메탈 서버를 강력히 권장합니다.프로덕션 검증자 참고 사양
참고로, Injective 메인넷의 프로덕션 검증자들은 일반적으로 다음 범위의 하드웨어를 운영합니다:
블록 처리에는 코어 수보다 높은 싱글 스레드 성능(부스트 클럭)이 더 중요합니다. 네트워크 요구 사항은 사양 표에 명시된 최소 1 Gbps를 훨씬 상회합니다. 프로덕션 검증자는 일관된 피어 연결성과 빠른 블록 전파를 위해 10 Gbps 이상의 회선에서 이점을 얻습니다.
RPC 노드
실시간 체인 데이터를 제공하는 비검증자 노드도 비슷한 요구 사항을 갖습니다. 슬래싱 위험은 없지만, 성능이 부족한 노드는 체인 팁에서 뒤처지고 신뢰할 수 없는 데이터를 제공하게 됩니다.스토리지
디스크 I/O 요구 사항
디스크 처리량은 Injective 노드에서 가장 흔한 병목 지점입니다. 체인은 잠재적으로 큰 트랜잭션 페이로드와 함께 약 650ms마다 블록을 생성하므로 지속적으로 높은 IOPS가 필요합니다.- 베어메탈: 로컬 NVMe 드라이브가 이상적입니다. 여러 NVMe 드라이브에 걸친 RAID0이 최고의 처리량을 제공합니다.
- 클라우드 (GCP): 표준 영구 디스크(
pd-balanced,pd-ssd)는 종종 필요한 IOPS를 유지할 수 없습니다. 체인 데이터 디렉터리에는 RAID0 구성의 로컬 SSD를 사용하세요. 로컬 SSD는 휘발성이지만 체인 상태는 스냅샷에서 쉽게 복구할 수 있습니다. 또는 IOPS와 처리량을 명시적으로 프로비저닝한hyperdisk-balanced또는hyperdisk-extreme을 프로비저닝하세요. - 클라우드 (AWS): 프로비저닝된 IOPS와 함께
io2또는gp3볼륨을 사용하세요. 인스턴스 스토어 NVMe(예:i3,i4i인스턴스)가 최고의 성능을 제공합니다.
체인 데이터 증가
Injective 체인 데이터는 하루에 약 10-15 GB씩 증가합니다. 프루닝된 노드의 경우 디스크 공간을 회수하고 성능을 유지하기 위해 300-400 GB마다 새 스냅샷에서 복원하는 것이 좋습니다. 스냅샷 다운로드 링크는 Chain Portal의 스냅샷 페이지를 참조하세요.프루닝 구성
프루닝은 디스크 공간 절약을 위해 오래된 상태를 제거하지만, 그 자체로 CPU와 I/O를 많이 사용합니다. 성능이 부족한 하드웨어에서는 프루닝 프로세스로 인해 노드가 체인 팁에서 뒤처질 수 있습니다. 노드가 지연되고 하드웨어 제한이 의심되는 경우:- 프루닝 오버헤드를 없애기 위해
app.toml에서pruning = "nothing"설정을 고려하세요 - 대신 주기적으로 노드를 중지하고 스냅샷에서 복원하여 디스크 사용량을 관리하세요
- 무중단 운영을 위해서는 두 개의 노드를 운영하며 롤링 방식으로 스냅샷 복구를 수행하세요
스토리지 레이아웃
프로덕션 검증자는 일반적으로 두 개의 NVMe 드라이브를 다음 구성 중 하나로 운영합니다:
두 레이아웃 모두 이중화를 제공하지 않지만, 체인 상태에는 이중화가 필요하지 않습니다. Injective의 1초 미만 블록 타임 요구 사항을 충족하려면 RAID0을 권장합니다. 드라이브가 고장 나면 스냅샷에서 복구하세요.
베어메탈 vs 클라우드
검증자 노드에는 베어메탈 서버를 강력히 권장합니다. 1초 미만 블록 타임에 필요한 일관된 CPU 클럭 속도와 저지연 NVMe 스토리지는 공유 클라우드 인프라에서 보장하기 어렵습니다. 클라우드 배포는 올바르게 프로비저닝된 경우(위의 스토리지 안내 참조) 비검증자 노드에서 작동할 수 있지만, 운영자는 신뢰성을 유지하기 위해 모니터링과 운영 도구에 더 많은 투자를 해야 합니다.참고 클라우드 인스턴스 유형
다음 인스턴스 유형은 Injective 노드에서 검증되었습니다. 프로비저닝 시 시작점으로 사용하세요.성능을 위해서는 (영구 디스크가 아닌) 로컬 SSD가 있는 클라우드 인스턴스가 필수적입니다. 표준 영구 디스크(
pd-balanced, pd-ssd)는 Injective의 블록 처리량에 필요한 IOPS를 유지할 수 없습니다. 로컬 SSD는 휘발성이지만 체인 상태는 스냅샷에서 복구할 수 있습니다.네트워킹 및 피어링
노드가 동기화를 유지하려면 건강한 피어 세트가 필요합니다. 피어링이 부족하면, 특히 검증자 세트 대다수와 멀리 떨어진 리전에서는 간헐적인 동기화 지연이 발생할 수 있습니다.- 최소 15-25개의 활성 피어를 유지하세요.
curl -s localhost:26657/net_info | jq '.result.n_peers'로 확인하세요 - 노드가 항상 신뢰할 수 있는 연결을 유지하도록
config.toml에 persistent peers를 구성하세요. 커뮤니티가 유지 관리하는 피어 목록은 피어 검색을 참조하세요 - Injective 피어가 적은 리전(예: 아시아-태평양)의 노드는 일관된 동기화를 유지하기 위해 추가 persistent peers가 필요할 수 있습니다
- 더 낮은 지연 시간과 더 일관된 라우팅을 위해 클라우드 제공자의 Premium Tier 네트워킹을 사용하세요