우리는 여러 노드가 있는 Jenkins 서버를 실행하고 있습니다. 시간이 좀 지나고 점점 더 많은 프로젝트가 인스턴스에 추가된 후 여러 문제에 직면하게 되었습니다(해결할 사람이 적지만 이는 또 다른 주제입니다).
정말로 우려되는 점은 우리가 서버로 사용하는 VM의 크기입니다. 저장된 데이터의 양이 10TB를 초과하며 계속해서 증가할 것입니다(수년/수십년 후에 아티팩트에 액세스해야 함).
이 시점에서 제가 궁금해하는 질문은 일반적으로 이러한 대규모 설치에 대한 경험이 있는 사람이 있는지, 적절하게 관리하지 않을 경우 홀 시스템에 어떤 일이 발생할 수 있는지, 그리고 여기에서 취해야 할 권장 조치에 대한 추정치를 제공할 수 있는지 여부입니다.
여기서 우리가 어디로 가고 싶은지는 불분명합니다. 경험이 많은 사람들이 어떻게 할지에 대한 의견을 좀 듣고 싶습니다.
답변1
용량 계획에는 현재 작업 방식에 드는 비용이 얼마나 되는지 조직에 알려주는 것도 포함됩니다.
내년 정도에 얼마나 많은 공간이 필요한지 추정해 보세요. 조금 모아서 75% 정도 채우도록 계획하면 약간의 여유가 있습니다. 사용 가능한 용량뿐만 아니라 하나의 LUN/파일 시스템/스토리지 어레이의 최대 크기를 초과하여 예상되는 비용을 추가하십시오. 중복 저장 및 백업 비용도 추가됩니다.
비용이 적게 드는 대안을 제공하십시오.
"이전 빌드 삭제"는 보존을 제어하는 Jenkins 옵션입니다. 실제 요구 사항은 가격표가 알려지면 나올 수 있습니다. 그러나 많은 조직에서는 IT 비용을 직접 지불하지 않으므로 사업부에서는 신경 쓰지 않을 수 있습니다.
오래된 유물을 얼마나 미리 요청할 수 있는지 토론하십시오. 며칠 안에 도착한다는 것은 냉장 보관 계층에 있을 수 있다는 것을 의미합니다. 백업 테이프는 온라인 시스템보다 훨씬 저렴할 수 있습니다. 그리고 다른 미디어를 사용하는 별도의 백업 시스템은 데이터가 "수십 년" 동안 생존할 가능성을 높여줍니다. 40년 된 데이터를 유지하는 데 사용할 수 있는 하드웨어와 인력을 보유하면 비용이 얼마나 많이 들 수 있는지 알아보십시오.
출력이 얼마나 재현 가능한지 알아보세요. 모든 입력이 버전 제어에 있고 출력이 일관적이라면 출력을 오랫동안 보관할 필요가 없을 수도 있습니다. 하지만 이를 위해서는 규율 있는 절차가 필요합니다.특히 소프트웨어를 구축하는 것은 출력을 결정적으로 만드는 것이 쉽지 않습니다.