Upgrade to Pro — share decks privately, control downloads, hide ads and more …

新機能エラスティックボリュームについて

 新機能エラスティックボリュームについて

2017.02.27 社内勉強会の資料です

Dfa36f596af5e15d0b28bac7516b1f81?s=128

One compath

March 02, 2017
Tweet

More Decks by One compath

Other Decks in Technology

Transcript

  1. インフラ技術G 竹内 EBSの新機能としてエラスティックボリューム

  2. EBS (Elastic Block Store)の新機能として ボリュームサイズの拡張 パフォーマンスの調整 ボリュームタイプの変更 を利用中(オンライン)に行うことができます。

  3. Amazon EBSのアップデート – 新機能エラスティックボリュームが全てを変える https://aws.amazon.com/jp/blogs/news/amazon-ebs-update-new-elastic-volumes-change-everything/

  4. ・ワークロードの変化 (例:汎用SSDボリューム → スループット最適化HDDボリューム) ・突発的な需要への対応 (例:月末の3日間だけIOPSを高く設定し、処理が終わったら元に戻す) ・ストレージの増加 (例:100GBのボリューム → 500GBボリュームへ変更)

  5. ①インスタンスをSTOP ②拡張したいEBSのスナップショットを作成   ・この時に拡張サイズを指定 ③現状のEBSをデタッチ ④新しいEBSをアタッチ ⑤インスタンスをSTART ⑥リサイズコマンドにてサイズ変更を反映 ⑦古いEBSを削除

  6. エラスティックボリュームは ①AWSのコンソール画面でEBSのサイズを変更 ②リサイズコマンドにてサイズ変更を反映 のみで完了。

  7. None
  8. None
  9. None
  10. None
  11. None
  12. 通常数秒でmodifying→optimizingになり、この時点でファイルシステムの拡張作業ができ 新しいボリュームの容量やタイプが利用可能となる。( optimizingは最大24時間かかることもある) ※費用は、optimizingになったタイミングで新構成を基準に計算されることになる。

  13. None
  14. 短時間で多く変更すると、 ボリューム制限につき最大修正率に達しました。 EBSボリュームにつき修正の間で少なくとも6時間待ってください。

  15. None
  16. # df -h Filesystem Size Used Avail Use% Mounted on

    /dev/mapper/VolGroup-lv_root 6.5G 3.1G 3.1G 51% / tmpfs 7.5G 0 7.5G 0% /dev/shm /dev/xvda1 477M 110M 342M 25% /boot /dev/xvdg 246G 62M 234G 1% /log /dev/xvdf 500G 239M 500G 1% /data
  17. # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda

    202:0 0 8G 0 disk tqxvda1 202:1 0 500M 0 part /boot mqxvda2 202:2 0 7.5G 0 part tqVolGroup-lv_root (dm-0) 253:0 0 6.7G 0 lvm / mqVolGroup-lv_swap (dm-1) 253:1 0 816M 0 lvm [SWAP] xvdb 202:16 0 30G 0 disk xvdg 202:96 0 250G 0 disk /log xvdf 202:80 0 800G 0 disk /data
  18. ◆Linux ext2、ext3、または ext4 ファイルシステム # resize2fs /dev/xvdf (xvdf は適時置き換えてください) ◆Linux xfsファイルシステムの場合

    # xfs_growfs -d /data (/data適時置き換えてください) ※ xfsprogsは、 yum install xfsprogsで入れる必要があります。 で実行します。
  19. # file -s /dev/xvdf /dev/xvdf: SGI XFS filesystem data (blksz

    4096, inosz 256, v2 dirs)
  20. # xfs_growfs -d /data meta-data=/dev/xvdf isize=256 agcount=4, agsize=32768000 blks =

    sectsz=512 attr=2, projid32bit=0 data = bsize=4096 blocks=131072000, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal bsize=4096 blocks=64000, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 data blocks changed from 131072000 to 209715200 1秒かからず終わりました。
  21. # df -h Filesystem Size Used Avail Use% Mounted on

    /dev/mapper/VolGroup-lv_root 6.5G 3.2G 3.1G 51% / tmpfs 7.5G 0 7.5G 0% /dev/shm /dev/xvda1 477M 110M 342M 25% /boot /dev/xvdg 246G 62M 234G 1% /log /dev/xvdf 800G 239M 800G 1% /data
  22. ちなみに、ボリュームサイズを小さくするのはできません。

  23. ◆CloudWatchで監視しアラームを設定 ・IOPS値の増加や、ボリュームタイプ変更 ・空き容量をモニタリング拡張 ・IOPSの削減やボリュームタイプ変更の変更

  24. ・サービス停止なしに変更できそう。  →AWS公式サイトにはダウンタイムはありませんと記述あり。   でも念のためAWSの方に確認したい。 ・コスト削減できそう。 →作業工数削減、EBS容量を無駄に大きくしなくていい。 ・急な変更ができるため役に立ちそう。 ・頻繁な変更について制限がありそうなので要確認。

  25. 以上です。ありがとうございました。