AWSS3のPostgreSQLバックアップメソッドの機能

[[email protected] ~]# df -h /mnt

Filesystem                            Size Used Avail Use% Mounted on

34.207.216.29:/s9s-postgresql-backup  8.0E 0 8.0E 0% /mnt

では、簡単なテストを実行しましょう：

[email protected][local]:54311 postgres# \l+ test

                                                List of databases

Name |  Owner | Encoding |   Collate | Ctype | Access privileges |  Size | Tablespace | Description

------+----------+----------+-------------+-------------+-------------------+---------+------------+-------------

test | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 |                   | 2763 MB | pg_default |

(1 row)

[[email protected] ~]# date ; time pg_dump -d test | gzip -c >/mnt/test.pg_dump.gz ; date

Sun 27 Oct 2019 06:06:24 PM PDT



real    0m29.807s

user    0m15.909s

sys     0m2.040s

Sun 27 Oct 2019 06:06:54 PM PDT

S3バケットの最終更新タイムスタンプは約1分後です。これは、前述のように、AmazonS3データ整合性モデルと関係があります。

より徹底的なテストがあります：

~ $ for q in {0..20} ; do touch /mnt/touched-at-$(date +%Y%m%d%H%M%S) ;

sleep 1 ; done



~ $ aws s3 ls s3://s9s-postgresql-backup | nl

    1      2019-10-27 19:50:40          0 touched-at-20191027194957

    2      2019-10-27 19:50:40          0 touched-at-20191027194958

    3      2019-10-27 19:50:40          0 touched-at-20191027195000

    4      2019-10-27 19:50:40          0 touched-at-20191027195001

    5      2019-10-27 19:50:40          0 touched-at-20191027195002

    6      2019-10-27 19:50:40          0 touched-at-20191027195004

    7      2019-10-27 19:50:40          0 touched-at-20191027195005

    8      2019-10-27 19:50:40          0 touched-at-20191027195007

    9      2019-10-27 19:50:40          0 touched-at-20191027195008

   10      2019-10-27 19:51:10          0 touched-at-20191027195009

   11      2019-10-27 19:51:10          0 touched-at-20191027195011

   12      2019-10-27 19:51:10          0 touched-at-20191027195012

   13      2019-10-27 19:51:10          0 touched-at-20191027195013

   14      2019-10-27 19:51:10          0 touched-at-20191027195014

   15      2019-10-27 19:51:10          0 touched-at-20191027195016

   16      2019-10-27 19:51:10          0 touched-at-20191027195017

   17      2019-10-27 19:51:10          0 touched-at-20191027195018

   18      2019-10-27 19:51:10          0 touched-at-20191027195020

   19      2019-10-27 19:51:10          0 touched-at-20191027195021

   20      2019-10-27 19:51:10          0 touched-at-20191027195022

   21      2019-10-27 19:51:10          0 touched-at-20191027195024

言及する価値のある別の問題：さまざまな構成で遊んだ後、ゲートウェイと共有を作成および破棄した後、ファイルゲートウェイをアクティブ化しようとしたときに、内部エラーが発生しました：

コマンドラインに詳細が表示されますが、問題は示されていません。

~$ curl -sv "http://107.22.30.30/?gatewayType=FILE_S3&activationRegion=us-east-1"

*   Trying 107.22.30.30:80...

* TCP_NODELAY set

* Connected to 107.22.30.30 (107.22.30.30) port 80 (#0)

> GET /?gatewayType=FILE_S3&activationRegion=us-east-1 HTTP/1.1

> Host: 107.22.30.30

> User-Agent: curl/7.65.3

> Accept: */*

>

* Mark bundle as not supporting multiuse

< HTTP/1.1 500 Internal Server Error

< Date: Mon, 28 Oct 2019 06:33:30 GMT

< Content-type: text/html

< Content-length: 14

<

* Connection #0 to host 107.22.30.30 left intact

Internal Error~ $

このフォーラムの投稿は、私の問題が、作成したVPCエンドポイントに関係している可能性があることを指摘しています。私の修正は、さまざまなiSCSI試行錯誤の実行中にセットアップしたVPCエンドポイントを削除することでした。

S3は保存データを暗号化しますが、NFSワイヤトラフィックはプレーンテキストです。つまり、tcpdumpパケットダンプは次のとおりです。

23:47:12.225273 IP 192.168.0.11.936 > 107.22.30.30.2049: Flags [P.], seq 2665:3377, ack 2929, win 501, options [nop,nop,TS val 1899459538 ecr 38013066], length 712: NFS request xid 3511704119 708 getattr fh 0,2/53

[email protected]@.......k.......        ...c..............

q7s..D.......PZ7...........................4........omiday.can.local...................................................5.......]...........!....................C...

..............&...........]....................# inittab is no longer used.

#

# ADDING CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.

#

# Ctrl-Alt-Delete is handled by /usr/lib/systemd/system/ctrl-alt-del.target

#

# systemd uses 'targets' instead of runlevels. By default, there are two main targets:

#

# multi-user.target: analogous to runlevel 3

# graphical.target: analogous to runlevel 5

#

# To view current default target, run:

# systemctl get-default

#

# To set a default target, run:

# systemctl set-default TARGET.target

.....   .........0..

23:47:12.331592 IP 107.22.30.30.2049 > 192.168.0.11.936: Flags [P.], seq 2929:3109, ack 3377, win 514, options [nop,nop,TS val 38013174 ecr 1899459538], length 180: NFS reply xid 3511704119 reply ok 176 getattr NON 4 ids 0/33554432 sz -2138196387

このIEEドラフトが承認されるまで、AWSの外部から接続するための唯一の安全なオプションは、VPNトンネルを使用することです。これによりセットアップが複雑になり、オンプレミスのNFSオプションは、後で説明するFUSEベースのツールよりも魅力的ではなくなります。

iSCSI

このオプションは、AWS StorageGatewayVolumeサービスによって提供されます。サービスが構成されたら、LinuxiSCSIクライアントのセットアップセクションに進みます。

NFSよりもiSCSIを使用する利点は、Amazonクラウドのネイティブバックアップ、クローン作成、およびスナップショットサービスを利用できることにあります。詳細とステップバイステップの手順については、AWSバックアップ、ボリュームクローン作成、EBSスナップショットへのリンクをたどってください

多くの利点がありますが、多くのユーザーを失望させる可能性のある重要な制限があります。パブリックIPアドレスを介してゲートウェイにアクセスすることはできません。したがって、NFSオプションと同様に、この要件によりセットアップが複雑になります。

明確な制限があり、このセットアップを完了できないと確信していましたが、それでも、それがどのように行われるかを感じたいと思いました。ウィザードはAWSMarketplaceの設定画面にリダイレクトします。

マーケットプレイスウィザードはセカンダリディスクを作成しますが、サイズであるため、ホストのセットアップ手順に示されているように、必要な2つのボリュームを追加する必要があります。ストレージ要件が満たされていない場合、ウィザードはローカルディスク構成画面でブロックします：

Amazonマーケットプレイスの設定画面をご覧ください：

SSH経由でアクセスできるテキストインターフェイスがあります（ユーザーsguserとしてログイン）これは、基本的なネットワークトラブルシューティングツールと、WebGUIでは実行できないその他の構成オプションを提供します。

~ $ ssh [email protected]

Warning: Permanently added 'ec2-3-231-96-109.compute-1.amazonaws.com,3.231.96.109' (ECDSA) to the list of known hosts.

'screen.xterm-256color': unknown terminal type.




      AWS Storage Gateway Configuration



      #######################################################################

      ##  Currently connected network adapters:

      ##

      ##  eth0: 172.31.1.185

      #######################################################################



      1: SOCKS Proxy Configuration

      2: Test Network Connectivity

      3: Gateway Console

      4: View System Resource Check (0 Errors)



      0: Stop AWS Storage Gateway



      Press "x" to exit session



      Enter command:

その他の重要なポイント：

• NFSセットアップとは異なり、ボリュームゲートウェイのFAQセクションに記載されているようにS3ストレージに直接アクセスすることはできません。
• AWSのドキュメントでは、接続のパフォーマンスとセキュリティを向上させるために、iSCSI設定をカスタマイズする必要があります。

~/mnt/s9s $ time pg_dump -d test | gzip -c >test.pg_dump-$(date +%Y%m%d-%H%M%S).gz

real    0m35.761s

user    0m16.122s

sys     0m2.228s

~/mnt/s9s $ aws s3 ls s3://s9s-postgresql-backup

2019-10-28 03:16:03   79110010 test.pg_dump-20191028-031535.gz

sqlite-devel-3.7.17-8.14.amzn1.x86_64

fuse-devel-2.9.4-1.18.amzn1.x86_64

fuse-2.9.4-1.18.amzn1.x86_64

system-rpm-config-9.0.3-42.28.amzn1.noarch

python36-devel-3.6.8-1.14.amzn1.x86_64

kernel-headers-4.14.146-93.123.amzn1.x86_64

glibc-headers-2.17-260.175.amzn1.x86_64

glibc-devel-2.17-260.175.amzn1.x86_64

gcc-4.8.5-1.22.amzn1.noarch

gcc48-4.8.5-28.142.amzn1.x86_64

mpfr-3.1.1-4.14.amzn1.x86_64

libmpc-1.0.1-3.3.amzn1.x86_64

libgomp-6.4.1-1.45.amzn1.x86_64

libgcc48-4.8.5-28.142.amzn1.x86_64

cpp48-4.8.5-28.142.amzn1.x86_64

python36-pip-9.0.3-1.26.amzn1.noarch

python36-libs-3.6.8-1.14.amzn1.x86_64

python36-3.6.8-1.14.amzn1.x86_64

python36-setuptools-36.2.7-1.33.amzn1.noarch

pip-3.6 install setuptools cryptography defusedxml apsw dugong pytest requests llfuse==1.3.6

~/temp/goofys $ ./goofys s9s-postgresql-backup ~/mnt/s9s/

~/mnt/s9s $ time pg_dump -d test | gzip -c >test.pg_dump-$(date +%Y%m%d-%H%M%S).gz



real    0m27.427s

user    0m15.962s

sys     0m2.169s



~/mnt/s9s $ aws s3 ls s3://s9s-postgresql-backup

2019-10-28 04:29:05   79110010 test.pg_dump-20191028-042902.gz