AERODISK 엔진: 재해 저항성. 1 부

안녕하세요, 하브르 독자 여러분! 이 기사의 주제는 AERODISK 엔진 스토리지 시스템의 재해 복구 도구 구현에 관한 것입니다. 처음에는 복제와 메트로 클러스터라는 두 도구에 대해 하나의 기사로 작성하고 싶었지만 안타깝게도 기사가 너무 길어서 기사를 두 부분으로 나누었습니다. 단순한 것에서 복잡한 것으로 가봅시다. 이 기사에서는 동기 복제를 설정하고 테스트합니다. 하나의 데이터 센터를 삭제하고 데이터 센터 간의 통신 채널을 끊고 어떤 일이 일어나는지 살펴보겠습니다.

고객들은 복제에 관해 다양한 질문을 자주 하기 때문에 복제본 설정 및 구현 테스트를 진행하기 전에 스토리지 복제가 무엇인지 간략하게 설명하겠습니다.

약간의 이론

스토리지 시스템의 복제는 여러 스토리지 시스템에서 동시에 데이터 ID를 보장하는 지속적인 프로세스입니다. 기술적으로 복제는 두 가지 방법으로 수행됩니다.

동기식 복제 – 이는 기본 스토리지 시스템에서 백업 시스템으로 데이터를 복사한 후 두 스토리지 시스템 모두에서 데이터가 기록되고 확인되었음을 의무적으로 확인하는 것입니다. 데이터가 기록된 것으로 간주되어 작업할 수 있는지는 양측(두 스토리지 시스템 모두)에서 확인한 후에야 가능합니다. 이를 통해 복제본에 참여하는 모든 스토리지 시스템의 데이터 ID가 보장됩니다.

이 방법의 장점:

• 데이터는 모든 스토리지 시스템에서 항상 동일합니다.

단점 :

• 높은 솔루션 비용(빠른 통신 채널, 고가의 광섬유, 장파 트랜시버 등)
• 거리 제한(수십km 이내)
• 논리적 데이터 손상에 대한 보호 기능이 없습니다(주 스토리지 시스템에서 데이터가 (의도적이든 실수로든) 손상된 경우 데이터는 항상 동일하므로 백업 시스템에서도 자동으로 즉시 손상됩니다(역설).

비동기식 복제 – 이는 또한 기본 스토리지 시스템에서 백업 스토리지 시스템으로 데이터를 복사하지만 어느 정도 지연이 발생하고 다른 쪽에서 쓰기를 확인할 필요가 없습니다. 데이터를 메인 스토리지 시스템에 기록한 후 바로 작업할 수 있으며, 백업 스토리지 시스템에서는 일정 시간이 지난 후 데이터를 사용할 수 있습니다. 물론 이 경우 데이터의 신원은 전혀 보장되지 않습니다. 백업 스토리지 시스템의 데이터는 항상 약간 "과거"입니다.

비동기식 복제의 장점:

• 저비용 솔루션(모든 통신 채널, 광학 옵션)
• 거리 제한 없음
• 백업 스토리지 시스템에서는 기본 스토리지 시스템에서 데이터가 손상되더라도(적어도 일정 기간 동안) 데이터 품질이 저하되지 않으며, 데이터가 손상된 경우 언제든지 복제본을 중지하여 백업 스토리지 시스템의 데이터 손상을 방지할 수 있습니다.

단점 :

• 서로 다른 데이터 센터의 데이터는 항상 동일하지 않습니다.

따라서 복제 모드 선택은 비즈니스 목표에 따라 달라집니다. 백업 데이터 센터에 기본 데이터 센터와 정확히 동일한 데이터가 포함되어 있는 것이 중요한 경우(즉, RPO = 0에 대한 비즈니스 요구 사항) 현금을 쏟아부어야 하고 동기식 데이터 센터의 한계를 견뎌야 합니다. 레플리카. 그리고 데이터 상태의 지연이 허용되거나 단순히 돈이 없다면 반드시 비동기식 방법을 사용해야 합니다.

또한 이러한 모드(보다 정확하게는 토폴로지)를 메트로 클러스터로 별도로 강조하겠습니다. 메트로 클러스터 모드에서는 동기식 복제가 사용되지만 일반 복제본과 달리 메트로 클러스터를 사용하면 두 스토리지 시스템 모두 활성 모드에서 작동할 수 있습니다. 저것들. 활성 데이터 센터와 대기 데이터 센터가 구분되지 않습니다. 애플리케이션은 물리적으로 서로 다른 데이터 센터에 위치한 두 개의 스토리지 시스템과 동시에 작동합니다. 이러한 토폴로지에서 사고 발생 시 가동 중지 시간은 매우 작습니다(RTO, 일반적으로 분). 이 기사에서는 메트로 클러스터의 구현을 고려하지 않을 것입니다. 이는 매우 크고 방대한 주제이기 때문입니다. 따라서 이 기사에 이어 별도의 다음 기사를 다룰 것입니다.

또한 스토리지 시스템을 사용한 복제에 관해 이야기할 때 많은 사람들이 다음과 같은 합리적인 질문을 하는 경우가 많습니다. > “많은 애플리케이션에는 자체 복제 도구가 있는데 스토리지 시스템에서 복제를 사용하는 이유는 무엇입니까? 더 나은가요, 아니면 더 나쁜가요?

여기에는 명확한 답이 없으므로 FOR 및 CONS 인수는 다음과 같습니다.

스토리지 복제에 대한 인수:

• 솔루션의 단순성. 하나의 도구를 사용하면 로드 유형 및 애플리케이션에 관계없이 전체 데이터 세트를 복제할 수 있습니다. 애플리케이션의 복제본을 사용하는 경우 각 애플리케이션을 별도로 구성해야 합니다. 2개 이상이면 이는 매우 노동 집약적이고 비용이 많이 듭니다(응용 프로그램 복제에는 일반적으로 각 응용 프로그램마다 무료가 아닌 별도의 라이센스가 필요합니다. 이에 대한 자세한 내용은 아래에서 설명합니다).
• 모든 애플리케이션, 모든 데이터 등 무엇이든 복제할 수 있으며 항상 일관성이 유지됩니다. 대부분의 애플리케이션에는 복제 기능이 없으며 스토리지 시스템의 복제본은 재해로부터 보호할 수 있는 유일한 방법입니다.
• 애플리케이션 복제 기능에 대해 초과 비용을 지불할 필요가 없습니다. 일반적으로 이는 스토리지 시스템 복제본에 대한 라이센스처럼 저렴하지 않습니다. 하지만 스토리지 복제에 대한 라이선스 비용은 한 번만 지불해야 하며, 애플리케이션 복제본에 대한 라이선스는 각 애플리케이션마다 별도로 구매해야 합니다. 그러한 애플리케이션이 많으면 비용이 꽤 들고 스토리지 복제를 위한 라이센스 비용도 엄청나게 낮아집니다.

스토리지 복제에 반대하는 주장:

• 애플리케이션을 통한 복제본은 애플리케이션 자체의 관점에서 볼 때 더 많은 기능을 갖고 있으며, 애플리케이션은 해당 데이터를 더 잘 알고 있으므로(분명히) 이를 사용하여 작업할 수 있는 옵션이 더 많습니다.
• 일부 응용 프로그램 제조업체는 타사 도구를 사용하여 복제를 수행하는 경우 데이터의 일관성을 보장하지 않습니다. *

* - 논쟁의 여지가 있는 논문. 예를 들어, 한 유명 DBMS 제조사는 자사의 DBMS는 자사의 수단을 통해서만 정상적으로 복제가 가능하며 나머지 복제(스토리지 시스템 포함)는 “사실이 아니다”라고 아주 오랫동안 공식적으로 선언해 왔다. 그러나 인생은 그렇지 않다는 것을 보여주었습니다. 아마도(그러나 확실하지는 않습니다) 이는 고객에게 더 많은 라이센스를 판매하려는 가장 정직한 시도가 아닐 것입니다.

결과적으로 대부분의 경우 스토리지 시스템에서 복제하는 것이 더 좋습니다. 이는 더 간단하고 저렴한 옵션이지만 특정 애플리케이션 기능이 필요한 복잡한 경우가 있으며 애플리케이션 수준 복제 작업이 필요합니다.

이론은 끝났으니 이제 실습

우리 연구실에서 복제본을 구성하겠습니다. 실험실 조건에서 우리는 두 개의 데이터 센터(실제로는 서로 다른 건물에 있는 것처럼 보이는 두 개의 인접한 랙)를 에뮬레이션했습니다. 스탠드는 광케이블로 서로 연결된 두 개의 Engine N2 스토리지 시스템으로 구성됩니다. Windows Server 2016을 실행하는 물리적 서버는 10Gb 이더넷을 사용하여 두 스토리지 시스템에 모두 연결됩니다. 스탠드는 매우 간단하지만 이것이 본질을 바꾸지는 않습니다.

개략적으로 보면 다음과 같습니다.

논리적으로 복제는 다음과 같이 구성됩니다.

이제 현재 가지고 있는 복제 기능을 살펴보겠습니다.
비동기식과 동기식의 두 가지 모드가 지원됩니다. 동기 모드가 거리와 통신 채널에 의해 제한된다는 것은 논리적입니다. 특히 동기 모드에서는 물리적으로 광섬유와 10기가비트 이더넷(또는 그 이상)을 사용해야 합니다.

동기식 복제에 지원되는 거리는 40km이며, 데이터 센터 간 광채널 지연 값은 최대 2밀리초입니다. 일반적으로 큰 지연이 발생하면 작동하지만 기록 중에 속도가 크게 느려지므로(이 역시 논리적임) 데이터 센터 간 동기식 복제를 계획하는 경우 광학 장치의 품질과 지연을 확인해야 합니다.

비동기 복제에 대한 요구 사항은 그다지 심각하지 않습니다. 더 정확하게는 전혀 존재하지 않습니다. 작동하는 모든 이더넷 연결이 가능합니다.

현재 AERODISK ENGINE 스토리지 시스템은 이더넷 프로토콜(구리 또는 광학을 통해)을 통해 블록 장치(LUN)에 대한 복제를 지원합니다. Fibre Channel을 통한 SAN 패브릭을 통한 복제가 필요한 프로젝트의 경우 현재 적절한 솔루션을 추가하고 있지만 아직 준비되지 않았으므로 우리의 경우 이더넷만 있습니다.

복제는 주니어 시스템에서 이전 시스템까지 또는 그 반대로 모든 ENGINE 시리즈 스토리지 시스템(N1, N2, N4) 간에 작동할 수 있습니다.

두 복제 모드의 기능은 완전히 동일합니다. 다음은 사용 가능한 항목에 대한 자세한 내용입니다.

• "일대일" 또는 "일대일" 복제, 즉 두 개의 데이터 센터(메인 센터와 백업 센터)가 있는 클래식 버전
• 복제는 "일대다" 또는 "일대다"입니다. 하나의 LUN을 여러 스토리지 시스템에 동시에 복제할 수 있습니다.
• 복제를 각각 활성화, 비활성화 및 "역방향"으로 활성화, 비활성화 또는 복제 방향 변경
• 복제는 RDG(Raid Distributed Group) 및 DDP(Dynamic Disk Pool) 풀 모두에 사용할 수 있습니다. 그러나 RDG 풀의 LUN은 다른 RDG에만 복제할 수 있습니다. DDP도 마찬가지다.

이 밖에도 소소한 기능들이 많이 있지만 나열할 특별한 의미는 없으며 설정하면서 언급하겠습니다.

복제 설정

설정 과정은 매우 간단하며 세 단계로 구성됩니다.

1. 네트워크 구성
2. 저장소 설정
3. 규칙(연결) 및 매핑 설정

복제 설정에서 중요한 점은 처음 두 단계는 원격 스토리지 시스템에서 반복하고, 세 번째 단계는 기본 스토리지 시스템에서만 반복해야 한다는 것입니다.

네트워크 리소스 설정

첫 번째 단계는 복제 트래픽이 전송될 네트워크 포트를 구성하는 것입니다. 이렇게 하려면 프런트엔드 어댑터 섹션에서 포트를 활성화하고 해당 IP 주소를 설정해야 합니다.

그런 다음 풀(이 경우 RDG)과 복제용 가상 IP(VIP)를 생성해야 합니다. VIP는 스토리지 컨트롤러(방금 구성한 포트)의 두 "물리적" 주소에 연결된 유동 IP 주소입니다. 이것이 기본 복제 인터페이스가 됩니다. 태그가 지정된 트래픽을 처리해야 하는 경우 VIP가 아닌 VLAN을 사용하여 작동할 수도 있습니다.

복제본용 VIP를 생성하는 프로세스는 I/O(NFS, SMB, iSCSI)용 VIP를 생성하는 과정과 크게 다르지 않습니다. 이 경우 일반 VIP(VLAN 없음)를 생성하지만 복제용임을 나타내야 합니다(이 포인터가 없으면 다음 단계에서 규칙에 VIP를 추가할 수 없습니다).

VIP는 VIP가 이동하는 IP 포트와 동일한 서브넷에 있어야 합니다.

물론 다른 IP를 사용하여 원격 스토리지 시스템에서 이러한 설정을 반복합니다.
서로 다른 스토리지 시스템의 VIP는 서로 다른 서브넷에 있을 수 있으며, 가장 중요한 것은 이들 사이에 라우팅이 있다는 것입니다. 우리의 경우 이 예가 정확하게 표시됩니다(192.168.3.XX 및 192.168.2.XX).

이로써 네트워크 부분의 준비가 완료되었습니다.

저장소 설정

복제본에 대한 스토리지 설정은 특수 메뉴 "복제 매핑"을 통해 매핑을 수행한다는 점만 평소와 다릅니다. 그렇지 않으면 모든 것이 일반 설정과 동일합니다. 이제 순서대로.

이전에 생성된 풀 R02에서 LUN을 생성해야 합니다. 이를 생성하고 LUN1이라고 부르겠습니다.

또한 동일한 크기의 원격 스토리지 시스템에 동일한 LUN을 생성해야 합니다. 우리는 만듭니다. 혼동을 피하기 위해 원격 LUN을 LUN1R이라고 부르겠습니다.

이미 존재하는 LUN을 가져와야 하는 경우 복제본을 설정하는 동안 호스트에서 이 운영 LUN을 마운트 해제하고 원격 스토리지 시스템에 동일한 크기의 빈 LUN을 생성하기만 하면 됩니다.

스토리지 설정이 완료되었으니 복제 규칙 생성을 진행해 보겠습니다.

복제 규칙 또는 복제 링크 설정

현재 기본 LUN이 될 스토리지 시스템에 LUN을 생성한 후 스토리지 시스템 1의 복제 규칙 LUN1을 스토리지 시스템 1의 LUN2R로 구성합니다.

설정은 “원격 복제” 메뉴에서 합니다.

규칙을 만들어 보겠습니다. 이렇게 하려면 복제본 수신자를 지정해야 합니다. 여기서는 연결 이름과 복제 유형(동기 또는 비동기)도 설정합니다.

"원격 시스템" 필드에 스토리지 시스템2을 추가합니다. 추가하려면 관리 IP 스토리지 시스템(MGR)과 복제를 수행할 원격 LUN의 이름(이 경우 LUN1R)을 사용해야 합니다. 제어 IP는 연결 추가 단계에서만 필요하며, 복제 트래픽은 이를 통해 전송되지 않으며, 이를 위해 이전에 구성된 VIP가 사용됩니다.

이미 이 단계에서 "일대다" 토폴로지에 대해 둘 이상의 원격 시스템을 추가할 수 있습니다. 아래 그림과 같이 "노드 추가" 버튼을 클릭하세요.

우리의 경우에는 원격 시스템이 하나뿐이므로 이것으로 제한합니다.

규칙이 준비되었습니다. 모든 복제 참가자에게 자동으로 추가된다는 점에 유의하세요(우리의 경우에는 두 명이 있습니다). 원하는 수의 LUN에 대해 원하는 만큼 규칙을 생성할 수 있습니다. 예를 들어 로드 밸런싱을 위해 LUN의 일부를 스토리지 시스템 1에서 스토리지 시스템 2로 복제하고, 반대로 나머지 부분은 스토리지 시스템 2에서 스토리지 시스템 1로 복제할 수 있습니다.

저장 시스템1. 생성 직후 동기화가 시작되었습니다.

저장 시스템2. 동일한 규칙이 표시되지만 동기화가 이미 종료되었습니다.

스토리지 시스템 1의 LUN1은 기본 역할, 즉 활성 상태입니다. 스토리지 시스템 1의 LUN2R은 보조 역할을 합니다. 즉, 스토리지 시스템 1에 장애가 발생할 경우 대기 상태입니다.
이제 LUN을 호스트에 연결할 수 있습니다.

FC를 통해서도 연결이 가능하지만 iSCSI를 통해 연결하겠습니다. 복제본에서 iSCSI LUN을 통해 매핑을 설정하는 것은 실제적으로 일반적인 시나리오와 다르지 않으므로 여기서는 자세히 다루지 않겠습니다. 이 프로세스는 "빠른 설치".

유일한 차이점은 "Replication Mapping" 메뉴에서 매핑을 생성한다는 것입니다.

매핑을 설정하고 LUN을 호스트에 제공했습니다. 호스트가 LUN을 확인했습니다.

로컬 파일 시스템으로 포맷합니다.

이것으로 설정이 완료되었습니다. 다음에 테스트가 올 것입니다.

테스트

우리는 세 가지 주요 시나리오를 테스트할 것입니다.

1. 일반 역할 전환 보조 > 기본. 예를 들어, 주 데이터 센터에서 일부 예방 작업을 수행해야 하는 경우 정기적인 역할 전환이 필요하며, 이 기간 동안 데이터를 사용할 수 있도록 백업 데이터 센터로 로드를 전송합니다.
2. 긴급 역할 전환 보조 > 기본(데이터 센터 장애). 이는 복제가 존재하는 주요 시나리오로, 장기간 동안 회사를 중단하지 않고 완전한 데이터 센터 장애를 극복하는 데 도움이 될 수 있습니다.
3. 데이터 센터 간의 통신 채널이 무너졌습니다. 어떤 이유로 데이터 센터 간의 통신 채널을 사용할 수 없는 상황에서 두 스토리지 시스템의 올바른 동작을 확인합니다(예: 굴착기가 잘못된 위치를 파고 어두운 광학 장치를 파손함).

먼저 LUN에 데이터 쓰기(임의의 데이터로 파일 쓰기)를 시작합니다. 스토리지 시스템 간의 통신 채널이 활용되고 있음을 즉시 확인할 수 있습니다. 이는 복제를 담당하는 포트의 부하 모니터링을 열어보면 이해하기 쉽다.

이제 두 스토리지 시스템 모두 "유용한" 데이터를 갖게 되었으며 테스트를 시작할 수 있습니다.

혹시 모르니 파일 중 하나의 해시 합계를 살펴보고 적어 보겠습니다.

정기적인 역할 전환

역할 전환 작업(복제 방향 변경)은 모든 스토리지 시스템에서 수행할 수 있지만 기본에서 매핑을 비활성화하고 기본이 될 보조에서 매핑을 활성화해야 하므로 두 시스템 모두로 이동해야 합니다. ).

아마도 이제 합리적인 질문이 떠오를 것입니다. 이것을 자동화하면 어떨까요? 대답은 간단합니다. 복제는 수동 작업에만 기반을 둔 간단한 재해 복구 수단입니다. 이러한 작업을 자동화하기 위해 완전히 자동화된 메트로 클러스터 모드가 있지만 구성이 훨씬 더 복잡합니다. 다음 기사에서는 메트로 클러스터 설정에 관해 글을 쓸 것입니다.

기본 스토리지 시스템에서는 녹화가 중지되도록 매핑을 비활성화합니다.

그런 다음 "원격 복제" 메뉴의 스토리지 시스템 중 하나(기본 또는 백업에 관계 없음)에서 REPL1 연결을 선택하고 "역할 변경"을 클릭합니다.

몇 초 후에 LUN1R(백업 스토리지 시스템)이 기본이 됩니다.

LUN1R을 스토리지 시스템2와 매핑합니다.

그런 다음 E: 드라이브가 호스트에 자동으로 연결되며 이번에는 LUN1R에서 "도착"되었습니다.

혹시라도 해시 합계를 비교합니다.

동일합니다. 테스트가 통과되었습니다.

장애 조치. 데이터 센터 장애

현재 정기 전환 후 기본 스토리지 시스템은 각각 스토리지 시스템 2와 LUN1R입니다. 사고를 에뮬레이션하기 위해 두 스토리지 컨트롤러의 전원을 모두 끕니다2.
더 이상 접근할 수 없습니다.

스토리지 시스템 1(현재 백업 시스템)에서 무슨 일이 일어나고 있는지 살펴보겠습니다.

운영 LUN(LUN1R)을 사용할 수 없는 것으로 확인됩니다. 로그, 정보 패널 및 복제 규칙 자체에 오류 메시지가 나타났습니다. 따라서 현재 호스트의 데이터를 사용할 수 없습니다.

LUN1의 역할을 기본으로 변경합니다.

호스트에 매핑을 수행 중입니다.

E 드라이브가 호스트에 나타나는지 확인하십시오.

해시를 확인합니다.

모든 것이 괜찮습니다. 스토리지 시스템은 가동 중이던 데이터센터의 붕괴에도 성공적으로 살아 남았습니다. 복제 "역방향"을 연결하고 백업 데이터 센터에서 LUN을 연결하는 데 소요된 대략적인 시간은 약 3분이었습니다. 실제 프로덕션에서는 모든 것이 훨씬 더 복잡하며 스토리지 시스템 작업 외에도 네트워크, 호스트, 애플리케이션에서 더 많은 작업을 수행해야 한다는 것이 분명합니다. 그리고 인생에서 이 기간은 훨씬 더 길어질 것입니다.

여기에는 모든 테스트가 성공적으로 완료되었지만 서두르지 말자고 쓰고 싶습니다. 메인 스토리지 시스템은 "거짓말"되어 있으며 "떨어졌을" 때는 기본 역할에 있었다는 것을 우리는 알고 있습니다. 갑자기 켜지면 어떻게 되나요? 데이터 손상과 동일한 두 가지 기본 역할이 있습니까? 지금 확인해 보겠습니다.
기본 스토리지 시스템을 갑자기 켜 보겠습니다.

몇 분 동안 로드된 후 짧은 동기화 후에 서비스로 돌아오지만 보조 역할을 합니다.

다 괜찮아. 분할 두뇌는 발생하지 않았습니다. 우리는 이것에 대해 생각했고, 저장 시스템이 "생활 중"에 어떤 역할을 했는지에 관계없이 항상 추락 후에는 보조 역할로 올라갑니다. 이제 우리는 데이터 센터 실패 테스트가 성공적이었다고 확신할 수 있습니다.

데이터센터 간 통신채널 장애

이 테스트의 주요 작업은 두 스토리지 시스템 간의 통신 채널이 일시적으로 끊겼다가 다시 나타나는 경우 스토리지 시스템이 이상하게 작동하지 않는지 확인하는 것입니다.
그래서. 저장 시스템 사이의 전선을 분리합니다(굴착기로 파냈다고 가정해 보겠습니다).

Primary에서는 Secondary와 아무런 관련이 없음을 알 수 있습니다.

Secondary에서는 Primary와 아무런 관련이 없음을 알 수 있습니다.

모든 것이 잘 작동하며 계속해서 주 스토리지 시스템에 데이터를 기록합니다. 즉, 백업 시스템과 다름이 보장됩니다. 즉, "분리"되었습니다.

몇 분 안에 우리는 통신 채널을 "수리"합니다. 스토리지 시스템이 서로 인식되는 즉시 데이터 동기화가 자동으로 활성화됩니다. 여기서는 관리자에게 필요한 것이 없습니다.

잠시 후 동기화가 완료됩니다.

연결이 복원되었고 통신 채널이 끊어져도 긴급 상황이 발생하지 않았으며 전원을 켠 후 자동으로 동기화가 이루어졌습니다.

조사 결과

우리는 무엇이 필요하고 왜, 장점은 어디에 있고 단점은 어디에 있는지에 대한 이론을 분석했습니다. 그런 다음 두 스토리지 시스템 간에 동기식 복제를 설정했습니다.

다음으로 정상 스위칭, 데이터센터 장애, 통신 채널 장애 등에 대한 기본 테스트를 진행했다. 모든 경우에 스토리지 시스템은 잘 작동했습니다. 수동 시나리오에서는 데이터 손실이 없으며 관리 작업이 최소한으로 유지됩니다.

다음번에는 상황을 복잡하게 만들고 이 모든 논리가 활성-활성 모드의 자동화된 메트로 클러스터에서 어떻게 작동하는지, 즉 두 스토리지 시스템이 모두 기본이고 스토리지 시스템 오류 발생 시 동작이 완전히 자동화되는 경우를 보여 드리겠습니다.

의견을 작성해 주시면 건전한 비판과 실용적인 조언을 기꺼이 듣겠습니다.

다음 번에 갈 때까지.

출처 : habr.com