Azure Native Qumulo 이제 EU, 영국 및 캐나다에서 사용 가능 – 상세 보기

"모든 기술 회사는 업데이트를 롤아웃하는 방법에 대한 교훈이 필요합니다. Qumulo처럼 하세요...". — 익명의 고객

작성자 :

새로운 월간 시리즈를 시작하면서 모든 고객이 경험하는 업그레이드에 대해 이야기해 봅시다. 고전적인 "재부팅 필요"이든 "너무 빨리 일어나서 놓친 경우"이든 관계없이 업그레이드는 죽음과 세금처럼 확실합니다.  

Qumulo는 상당히 정기적인 속도로 업그레이드가 출시되므로 이 분야에서 다르지 않습니다. Qumulo가 릴리스 3.3.2에서 다시 컨테이너로 OS를 구현했을 때 플랫폼 개념과 즉각적인 업그레이드도 도입했습니다. 대부분의 기본 수준에서 동일한 작업을 수행하며 대부분 동일한 방식으로 수행됩니다. 둘 다 모든 노드에서 이미지를 복사합니다. 둘 다 성공적인 업그레이드를 보장하기 위해 일련의 사전 테스트(일반적으로 비행 전 체크리스트라고 함)를 실행합니다. 마지막으로 둘 다 일종의 시스템 재시작을 하게 됩니다. 인스턴트의 경우 컨테이너, 플랫폼 또는 롤링 재부팅의 경우 노드입니다.

지원팀에서 묻는 가장 일반적인 질문 중 하나는 '내 업그레이드 경로는 무엇입니까?' 또는 '버전 X에서 버전 Y로 가장 잘 이동하는 방법'입니다.

릴리스 명명 체계에 대한 분석부터 시작하겠습니다.   

XYZa

어디에 

X는 회계 연도입니다.

Y는 0부터 시작하는 회계 분기입니다.

Z는 해당 분기의 릴리스입니다.

일부 추가 기능(예: 타사 지원 가능성, 펌웨어 및 간헐적인 버그 수정)이 포함된 경우 필요에 따라 제공됩니다.

예를 들어 5.3.4는 다음과 같습니다.

5회계연도, 4분기, 해당 분기의 XNUMX번째 릴리스.

이것이 왜 중요한가요? Qumulo에는 세 번째 숫자가 0으로 표시되는 "분기별 릴리스" 또는 매 분기의 첫 번째 릴리스가 있습니다. 이것에 대해 특별히 기발한 것은 없으며 달력 연도에 착륙하는 위치에 있습니다. 그러나 우리는 이를 다음 분기의 발판으로 사용할 것이므로 Qumulo 고객은 .0 분기별 릴리스마다 업그레이드해야 합니다.

저는 최근에 2년 동안 시스템을 손대지 않은 고객과 이야기를 나눴습니다. 고장나지 않았다면 고치지 마십시오(자세한 내용은 나중에 설명). .0 분기별 릴리스마다 업그레이드해야 했기 때문에 업그레이드 경로는 상상할 수 있을 만큼 길었습니다.

3.2.0 -> 3.3.0 -> 4.0.0.2 -> 4.1.0.1 -> 4.2.0 -> 4.3.0 -> 5.0.0.1 -> 5.1.0.1 -> 5.2.0.2 -> 5.3.0 -> 6.0.0.2 

업그레이드와 관련하여 다음으로 자주 듣는 질문은 '시간이 얼마나 걸리나요?'입니다. 즉각적인 업그레이드는 일반적으로 10초 이내에 이루어지며 응용 프로그램은 거의 신경쓰지 않는 것 같습니다. 플랫폼 업그레이드는 시스템이 부팅되는 데 걸리는 시간만큼 오래 걸립니다. 일반적으로 5-10분 정도 걸립니다. 위에 제시된 업그레이드 경로를 선택하고 Instant(I) 또는 Platform(P)인 경우 추가하면 – 

3.2.0(P) -> 3.3.0(I) -> 4.0.0.2(I) -> 4.1.0.1(I) -> 4.2.0(I) -> 4.3.0(P) -> 5.0.0.1. 5.1.0.1(I) -> 5.2.0.2(I) -> 5.3.0(P) -> 6.0.0.2(I) -> XNUMX(P) 

위의 내용을 감안할 때 플랫폼에 대해 8분을 가정하면 그 중 4분과 7분을 보고 있는 것입니다. 총 35분 주고 받기. 한 시간을 계획하고 좋은 낮잠을 자십시오.

플랫폼이 될지 또는 즉시 업그레이드가 될지 확인하기 위한 훌륭한 문서는 docs.qumulo.com 페이지 여기를 눌러 더 많은 정보를 찾으세요...  

이를 보고 6.0.0.2가 '즉시, 분기별'이라고 명확하게 명시되어 있는데 왜 플랫폼 업그레이드로 분류되었는지 궁금할 것입니다. 여기에서 다음 업그레이드 퀴즈가 시작됩니다.   

해당 차트를 아래로 스크롤하면 5.3.1에서 발생한 플랫폼 업그레이드가 있음을 알 수 있습니다. 분기별 6.0.0.2의 일부로 해당 버전을 출시하고 있으므로 해당 플랫폼 업그레이드는 분기별 릴리스로 푸시됩니다. 미묘하지만 찾고 있지 않으면 방심할 수 있습니다.  

우리가 이것에 활을 묶기 전에 제가 언급한 두 가지 마지막 사항이 작용할 것입니다. 첫 번째는 하드웨어 관련입니다. 무어의 법칙(RIP Gordon Moore, 당신은 좋은 성과를 거두었습니다)에 직접적으로 연결되어 있지는 않지만 하드웨어 발전은 순혈 속도로 이루어집니다. 따라서 올해 출시되는 하드 드라이브와 같은 무해한 제품은 2년 전에 만들어진 소프트웨어에 대해 테스트되지 않았습니다. Qumulo에서는 코드 내에서 내부 하드웨어 호환성 목록을 유지 관리합니다. 이들은 높은 기준을 보장하기 위해 엄격한 테스트를 거친 구성 요소입니다. 따라서 이전 릴리스에서 실행 중이고 교체가 필요한 경우 새 부품이 이전 소프트웨어에 대해 검증되지 않았을 수 있습니다. 우리는 때때로 이것을 보고 일반적으로 소프트웨어를 최신 릴리스로 업그레이드할 것입니다.   

주목해야 할 다른 항목은 복제입니다. Qumulo의 최신 버전을 사용하려면 서로 분기별로 두 번 릴리스해야 합니다(위 명명 체계에서 두 번째 숫자임). 업그레이드를 계획할 때 특히 예를 들어 소스보다 몇 주 전에 재해 복구 사이트를 업그레이드할 계획인 경우 이 점을 염두에 두십시오. 다음 달에 복제 및 관련 모범 사례에 대해 더 자세히 이야기하겠지만 지금은 질문, 의견 또는 우려 사항이 있는 경우 주저하지 말고 전용 Slack 채널에서 Qumulo 지원에 문의하십시오.

다음달까지…

관련 게시물

위쪽으로 스크롤