약 80여개의 서버가 있으면 각 서버를 군집화(클러스터화) 하려고 함.

클러스터화 방법

어찌됐든, 클러스터화를 통해서 iwinv의 마스터 서버까지 구해낼 수 있을까? 이것에 따라서 할 수 있는게 많이 달라질 듯. (마스터 서버 < 존 < iwinv) - 같은 master 서버면 hop = 3이 가능하지 않을까 생각함. (서버 A → virtio → 서버 B), 불가능 하다면 hop = 4 예상함

dev -> setup
1  gateway (172.16.0.1)  0.481 ms  0.432 ms  0.403 ms
2  169.254.93.81 (169.254.93.81)  0.381 ms  0.360 ms  0.338 ms
3  115.68.218.131 (115.68.218.131)  0.317 ms  0.297 ms  0.276 ms
4  * * *
5  115.68.222.99 (115.68.222.99)  0.592 ms  0.577 ms  0.599 ms
dev -> spot365tv.inde.biz
1  gateway (172.16.0.1)  0.731 ms  0.671 ms  0.634 ms
2  169.254.93.81 (169.254.93.81)  0.604 ms  0.577 ms  0.550 ms
3  * * *
4  * 115.68.216.3 (115.68.216.3)  1.727 ms  1.841 ms
5  115.68.139.66 (115.68.139.66)  0.841 ms 49.247.200.2 (49.247.200.2)  1.250 ms 115.68.139.66 (115.68.139.66)  1.574 ms
6  49.247.206.135 (49.247.206.135)  0.720 ms 115.68.139.70 (115.68.139.70)  0.989 ms  0.929 ms
7  49.247.206.135 (49.247.206.135)  0.546 ms  0.514 ms  0.499 ms
8  * * *
9  49.247.203.165 (49.247.203.165)  0.783 ms  0.775 ms  0.724 ms
dev -> connan tv
1  gateway (172.16.0.1)  0.202 ms  0.125 ms  0.117 ms
2  169.254.93.81 (169.254.93.81)  0.143 ms  0.138 ms  0.130 ms
3  115.68.220.224 (115.68.220.224)  54.405 ms  54.242 ms  54.121 ms
4  * * *
5  115.68.220.191 (115.68.220.191)  53.878 ms  53.873 ms  53.847 ms
traceroute to showtv24.inde.biz (115.68.220.208), 30 hops max, 60 byte packets
1  gateway (172.16.0.1)  1.064 ms  1.025 ms  0.997 ms
2  169.254.93.81 (169.254.93.81)  0.976 ms  0.956 ms  0.935 ms
3  115.68.218.50 (115.68.218.50)  636.471 ms  636.545 ms  636.528 ms
4  * * *
5  115.68.220.208 (115.68.220.208)  636.458 ms  636.421 ms  636.481 ms
오라클은... 확인 불가 (패킷이 모두 drop됨)

대충... 같은 존인지는 확인 되는듯. 그러나 같은 마스터 서버 여부는... 잘 모르겠음.

<aside> 🔔 iwinv: 마스터 서버 탈출에 4 hop 발생, 옆 서버 도착에 10 hop 발생 (메인 라우터에서 edge까지 4hop 필요한듯)

</aside>

oracle은 tcp ping을 사용해야 할 듯(icmp 패킷이 전부 drop돼서 확인이 불가함)

클러스터화를 해야하는 이유?

그냥 개별서버로 모니터링 하는것 보다 이점이 많은가?

  1. 알림의 그룹화 + 분석의 용이 (어느 정도로 정확할 지 모르겠으나, 상황에 따라서 master 서버 구분, 같은 존의 구분, 같은 호스팅사의 구분이 가능할 것으로 생각됨)
  2. 검사 정확성 향상 (기존에는 “이게 어디에 소속된건지” 알 수가 없어서 문제가 발생. 랜덤한 3개를 꼽았더니 다 같은 존이라면? 데이터의 가치가 줄어듦. 이제는 각 서버가 “랜덤으로 하되, 각 클러스터당 한 곳은 검사함” 이라고 조건을 걸면 빠짐 없이 검사할 수 있음)
  3. 패킷(비용)의 감소. (기존에 2번을 구현하려면 모든 서버에 패킷을 보냈어야 함. [서버수^2] 만큼의 패킷이 발생함. 그러나 이제는 [클러스터의 갯수]만큼만 패킷을 보내면 됨)