[Solana] 솔라나 벨리데이터 자동 재시작, 모니터링, 디스코드

*이 글은 솔라나 벨리데이터 운영에 참고하기 위해 공식 문서를 번역한 글입니다. 의역이 있어 원작자의 의도와 다른 해석이 있을 수 있습니다.

 

Add Solana to Your Exchange | Solana Docs

벨리데이터 자동 재시작

솔라나 벨리데이터 운영 시, 각 노드가 종료되면 자동으로 재시작하게 구성해야 놓치는 데이터가 최소화될 수 있다.

그러므로 솔라나 소프트웨어를 systemd 서비스로 돌리는 게 좋다.

 

---

벨리데이터 모니터링

솔라나는 모니터링을 위해 solana-watchtower 커맨드를 제공한다. 이 커맨드는 벨리데이터를 모니터링하고 solana-validator 프로세스가 비정상(unhealthy)일 때 이를 감지한다.

 

solana-watchtower --validator-identity <YOUR VALIDATOR IDENTITY>

 

솔라나가 잘 돌아가지 않을 때 Slack, Discord, Telegram, Twillio 등을 통해 알림으로 경고하도록 직접 구성할 수 있다.

 

ADDITIONAL HELP:
        To receive a Slack, Discord and/or Telegram notification on sanity failure,
        define environment variables before running `solana-watchtower`:

        export SLACK_WEBHOOK=...
        export DISCORD_WEBHOOK=...

        Telegram requires the following two variables:

        export TELEGRAM_BOT_TOKEN=...
        export TELEGRAM_CHAT_ID=...

        To receive a Twilio SMS notification on failure, having a Twilio account,
        and a sending number owned by that account,
        define environment variable before running `solana-watchtower`:

        export TWILIO_CONFIG='ACCOUNT=<account>,TOKEN=<securityToken>,TO=<receivingNumber>,FROM=<sendingNumber>'

 

solana-watchtower 실행 전 위처럼 알림을 받을 플랫폼 환경변수를 선언해서 문제 발생 시 바로 알림이 발송되게끔 설정해야할 듯하다.

- 슬랙 참고할 페이지 : https://api.slack.com/messaging/webhooks

 

자세한 내용은 solana-watchtower --help 로 확인 가능하다.

 

solana-watchtower --help 출력

 

[OPTIONS]

--interval <SECONDS> : 클러스터 체크 주기를 얼마로 할지 (기본설정 간격 : 1분)

--minimum-validator-identity-balance <SOL> : 벨리데이터 잔액이 얼마 이하로 내려가면 경고를 보낼지 (기본설정 : 10 SOL)

--unhealthy-threshole <COUNT> : 몇변 연속으로 실패했을 때 알림을 발생시킬지 (기본설정 : 1번)

 

---

새로운 소프트웨어 릴리스 발표

솔라나는 새 소프트웨어를 자주 출시한다. 한주당 약 1개 릴리스 꼴이라고 한다. 가끔 최신 버전에는 호환되지 않는 프로토콜 변경사항도 포함되어 있어서 블록 처리 오류를 방지하기 위해 적절한 시기마다 소프트웨어 업데이트를 해줘야 한다.

 

모든 종류(일반, 보안 등)의 공식 릴리스 발표는 #mb-announcement 라는 디스코드 채널로 전달된다. (mb는 메인넷 베타의 약자)

 

Discord - A New Way to Chat with Friends & Communities

 

스테이킹된 검증인과 마찬가지로 거래소에서 운영하는 검증인도 정상적인 출시 발표 후 영업일 기준 1~2일 이내에 최대한 빠르게 업데이트되어야 한다. 특히 보안 관련 릴리스는 더 긴급하게 조치해야할 수 있다.

 

원장 연속성

기본적으로 자신의 각 노드는 자신이 설정한 알려진 검증인(known validators) 중 하나가 제공한 스냅샷에서 부팅된다.

스냅샷은 체인의 현재 상태를 반영하지만 원장 기록을 완전히 다 포함하지는 않는다. 만약 자신의 노드 중 하나가 종료되고 새 스냅샷에서 부팅되는 경우, 그 노드의 원장에는 공백이 생길 수 있다.

 

이러한 문제를 방지하려면 solana-validator 커맨드에 --no-snapshot-fetch 매개변수를 추가해서 스냅샷 대신 원장 기록 데이터를 수신하자.

단 초기 부팅 시에는 --no-snapshot-fetch 매개변수를 전달하면 안된다. 노드를 제네시스 블록부터 끝까지 받아와 부팅할 수는 없기 때문이다. 먼저 스냅샷에서 부팅한 다음 --no-snapshot-fetch 재부팅 매개변수를 추가하자.

 

네트워크 나머지 부분에서 자신의 노드에 사용할 수 있는 원장 기록의 양은 언제든지 제한된다는 것을 유의하는 것은 매우 중요하다. 검증인은 한번 작동하기 시작하면 가동이 중지됐을 때 네트워크를 따라잡지 못할 수 있으며, 알려진 검증인에서 새 스냅샷을 다운로드 받아야 한다. 이렇게 하면 검증인의 원장 기록 데이터에 채울 수 없는 공백이 생긴다.

 

검증인 포트 노출 최소화

검증인은 다른 모든 솔라나 검증인의 인바운드 트래픽에 대해 다양한 udp, tcp 포트가 열려있어야 한다.

이게 가장 효율적인 작동 모드고 강력히 권장되지만, 다른 솔라나 검증인의 인바운드 트래픽만 요구하도록 검증인을 제한할 수 있다.

 

먼저 --restricted-repair-only-mode 인수를 추가한다. 이는 검증인이 나머지 검증인으로부터 푸시를 받지 않고 블록에 대해 계속 다른 검증인을 폴링해야하는 제한된 모드에서 작동하게 한다.

검증인은 Gossip과 ServeR("serve repair") 포트를 사용해 다른 검증인에게 UDP 패킷을 전송만 하고 Gossip과 Repair 포트에서는 UDP 패킷을 수신만 한다.

 

가십 포트는 양방향이고 벨리데이터를 클러스터의 나머지 부분과 계속 연결할 수 있다.

이제 Turbine을 사용할 수 없기 때문에, 검증인은 나머지 네트워크에서 새로운 블록들을 얻기 위해 repair 요청을 ServeR 에서 전송한다.

그러면 검증인이 다른 검증인으로부터 repair 포트에서 repair 응답을 받게 된다.

 

검증인이 하나나 여럿의 검증인에서만 블록을 요청하도록 제한하려면 먼저 해당 검증인에 대한 ID pubkey를 알아내 각 PUBKEY에 대한 --gossip-pull-validator PUBKEY --repair-validator PUBKEY 인수를 추가하면 된다. 이렇게 하면 추가한 각 검증인에서 자신의 검증인이 자원을 소모하게 되므로, 이 작업은 삼가해서 대상 검증인과 상의한 후에만 수행하도록 하자.

 

이제 검증인은 명시적으로 나열된 검증인과 Gossip, Repair, ServeR 포트들에서만 통신해야 한다.