Sun Developer Network 공식 블로그

호스팅 솔루션과 스토리지 유틸리티를 고려할때에는 여러가지 기억해두어야 할 사항들이 있습니다. 이러한 사항들의 대부분은 숫자로 측정이 가능하지만 몇몇은 (예를 들어 여러분 회사의 핵심 역량 같은) 그렇지 않을 수도 있습니다. 아래의 고려사항 및 요구사항은 필자가 고유의 솔루션을 만들기 혹은 스토리지 유틸리티를 활용하기 두개의 선택을 할 때에 고려했던 사항들에 대해 나열한 것입니다. 필자는 솔루션이 다음과 같은 혜택을 제공하기를 원했었습니다:

• 원격 백업으로 12 테라바이트 이상의 접근 가능한 스토리지 (한달에 1TB 정도를 사용한다고 가정)
• 아래와 같은 비용을 포함하여 일년이상 사용했을때 로컬에 위치하는 솔루션보다 좀 더 저렴한 월별 비용:
  • 하드웨어 비용
  • 전력 비용
  • 원격 호스팅 설비 비용
  • 네트워크 대역폭 비용
  • 시스템 관리자 비용

필자는 필자의 스토리지 소비 및 환경에 대한 몇가지 가정을 해 보았습니다. 여기서 숫자들은 모두 소숫점을 버렸습니다. 회사로 가정한다면 여러분은 분명 좀 더 공격 적으로 기대 사항들을 매핑시켰을 것입니다. 왜냐하면 모든 비용의 합산 및 비용의 정확성이 최종 비용을 고려하는데에 도움을 줄 것이기 때문입니다. 필자는 다음과 같이 가정 하였습니다:

• 월별 사용량: 한달에 1TB 정도를 백업한다고 가정
• 복구: 일년내내 두달에 한번꼴로 두번의 500MB 데이타 복구가 발생한다고 가정
• 접근 시간: "일반적인" 네트워크 지연시간으로 용납가능
• 접근 빈도: 100 Mbps 네트워크 접속으로 용납가능
• 안정성: 같은 장소에서 사용하고 있는 솔루션과 스토리지 유틸리티는 동일한 가용성을 가지고 있다고 가정

물론 필자가 비슷한 수준에서의 비교를 원했기 때문에 이 글의 범주에 들어가지 않는다고 생각한 수많은 것들이 있습니다. 개인의 스토리지 관리 능력이 좀 더 향상될 수록 비용 절감에 도움을 주는 좀 더 많은 솔루션들이 존재 합니다. 필자의 목표는 간결함 이였고 그러므로 몇가지 것들은 이 글의 범위에 넣지 않았습니다:

• 복잡한 로컬 스토리지와 네트워크 솔루션들 (이 글에서는 단일 X4500 장비를 네트워크를 통해 백업 한다고 가정함)
• 테잎 백업

필자는 아래 그림처럼 "간단하게" 일대일로 연결된 파일 기반의 백업 인프라가 존재한다고 가정합니다.

"간단하게" 일대일로 연결된 파일 기반의 백업 인프라

저의 구현은 다음과 같은 가정을 하고 있습니다:

시스템 설정을 위해:

1. 하나의 스토리지 풀을 만듭니다:
   
   

   zfs create media c0t1d0

   
   
2. 미디어 스토리지 풀 내에 파일 시스템을 생성합니다l:
   
   

   zfs create media/mypictures

   
   
3. 마운트포인트를 /export 로 변경합니다:
   
   

   zfs set mountpoint=/export/media/mypictures media/mypictures

   
   
4. NFS 를 이용해서 공유 가능하도록 설정합니다:
   
   

   zfs set sharenfs=on media/mypictures

   
   
5. 압축 기능을 사용합니다:
   
   

   zfs set compression=on media/pictures

   
   
6. 사진들을 media/pictures 디렉토리로 복사 합니다. (적정한 수준의 스냅샷을 만드는데 충분하도록)

우리의 첫번째 프로세스는 스냅샷을 만들고 이 스냅샷을 백업을 위해 Amazon S3 로 보내는 것으로 구성되어 있습니다. 이 시점에서 몇가지 가정이 필요 합니다:

• 여러분은 백업을 하려고 하는 볼륨 혹은 파일 시스템을 가지고 있어야 합니다 (위에서 생성했던 대로)
• 스냅샷 사이즈는 Amazon S3 라이센스 혹은 여러분과 Amazon S3 의 서비스 계약에 맞게 적절해야 합니다

우리가 진행할 단계는:

• 파일 시스템 스냅샷 생성하기
• 스냅샷을 데이타 스트림으로 변환하기
• 스냅샷 압축하기
• 적절한 메타데이타와 함께 Amazon S3 에 전송하기

스냅샷을 생성해서 저장하기 위해서는:

1. 스냅샷을 생성하기 위해 zfs snapshot 커맨드를 이용합니다. 필자는 /export/media/mypictures 디렉토리 전체를 스냅샷 했고 스냅샷을 아래와 같은 커맨드를이용해서 "20070607" 로 지었습니다:
   
   

   zfs snapshot media/mypictures@20070607

   
   

   스냅샷은 초기에 파일 시스템에 추가적인 공간을 차지하지 않아야 합니다. 파일이 변경될 수록 스냅샷 공간도 늘어나야 합니다. 왜냐하면 데이타의 변경이 반드시 복사가 되어야 하기 때문입니다.

2. 상대적으로 스냅샷 자체를 데이타 스트림으로 변경하는 것은 간단합니다. send 커맨드를 이용해서 스냅샷을 파일로 전송합니다:
   
   

   zfs send media/mypictures@20070607 > ~/backups/20070607

   
   
3. 우리는 또한 파이프를 통해서 압축을 할 수 있습니다. 그러므로 필자가 사용한 커맨드는 다음과 같습니다:
   
   

   zfs send media/mypictures@20070607 | gzip > ~/backups/20070607.gz

   
   
4. 마지막으로 우리는 스냅샷을 Amazon S3 에 전송할 수 있습니다.

여러분이 데이타를 잃어 버렸거나 여러분의 역사 중에 특정 시간대로 돌아가기 위해 스냅샷을 검색하고 복구 하는 과정은 역시 상대적으로 간단합니다. 간단히 위의 단계를 역순으로 수행하기만 하면 됩니다. 아래의 자바 코드를 살펴 보시기 바랍니다 (Amazon S3 Java REST libraries).

public static void main(String args[]) throws Exception {
        if (awsAccessKeyId.startsWith("<INSERT")) {
            System.err.println("Please examine S3Driver.java and update it with your credentials");
            System.exit(-1);
        }

        if (args.length < 2) {
            System.err.println("Get snapshot and write data needs 2 parameters: GetSnapshot key path");
            System.exit(-1);
        }        
        
        AWSAuthConnection conn =
            new AWSAuthConnection(awsAccessKeyId, awsSecretAccessKey);

        System.out.println("----- getting object -----");
        byte[] bytes = conn.get(bucketName, args[0], null).object.data;
        
        try {
            FileOutputStream fos = new FileOutputStream(args[1]);
            fos.write(bytes);
            fos.flush();
            fos.close();
        } catch (Exception e) {
            e.printStackTrace();
        }
    } 

gzip 으로 압축된 스냅샷을 가져 오면 압축을 풀기 위해 다음의 커맨드를 이용합니다:

# gunzip 20070607.gz

이제 여러분은 여러분의 스냅샷으로 무엇을 할지 결정해야 합니다. 필자는 현재의 mypictures 풀을 이동시키고 기존의 스냅샷을 복구 해서 "시간 여행" 을 하기로 결정하였습니다. 아래의 커맨드를 이용하였습니다:

# zfs rename media/mypictures media/mypictures.old
# zfs receive media/mypictures < 20070607

이게 끝입니다! /export/media/mypictures 는 2007년 6월 7일에 스냅샷 했었던 사진들로 보국 되었습니다!

Amazon S3 의 비용 청구는 아주 간단합니다. 필자는 크레딧 카드 정보를 미리 입력하였고 달마다 청구서를 받고 있습니다. 이 글을 위해 사용한 전체 스토리지의 비용 청구서의 복사본입니다.

Greetings from Amazon Web Services,

This e-mail confirms that your latest billing statement is available on the AWS 
web site. Your account will be charged the following:

Total: $0.09

Please see the Account Activity area of the AWS web site for detailed account 
information:

http://aws-portal.amazon.com/gp/aws/developer/account/index.html?action=activity
-summary

Thank you for your continuing interest in Amazon Web Services.

Sincerely,

Amazon Web Services

This message was produced and distributed by Amazon Web Services LLC, 1200 12th 
Avenue South, Seattle, Washington 98144-2734

• Amazon S3 사이즈 제한:"Terms of Use" 에서 Amazon S3 는 다음과 같이 기술하고 있습니다: "You may not, however, store 'objects' (as described in the user documentation) that contain more than 5Gb of data, or own more than 100 'buckets' (as described in the user documentation) at any one time." 결과적으로 우리들은 스냅샷을 적절하게 분할해서 Amazon S3 의 규정을 준수해야 합니다. 혹은 Amazon S3 와 협력해서 다른 방법을 찾을 수도 있을 것입니다. 이러한 제한은 HTTPS 프로토콜 자체의 길이 제약 때문에 완벽히 합리적이긴 합니다.
• 암호화: 써드 파티 스토리지 사이트에 전송되기 전에 데이타는 반드시 암호화 되어야 합니다.
• Cron Job: 시간별 스냅샷은 자동으로 만들어질 수도 있습니다.
• 비-자바: 스크립트로 모든 과정을 진행할 수 있으면 매우 훌륭할 것입니다. 그러나 키 생성 부분에서 필자는 포기 했고 필자의 전문인 자바 코드를 사용했습니다.