LinuxユーザーがイジるはじめてのAzure

LinuxユーザーがMicrosoft Azureを使いこなせるように応援するブログです

CentOS7からAzure FileストレージとLVMをいじる

ちょこちょこといろいろな方面から割と聞かれるため記事にしておきます。

 

Linuxユーザーにとってクラウドだろうがオンプレだろうが自宅のPCだろう

が、データの種別やアクセス頻度に応じてディスクレイアウトを定めるのは、

もはや常識ですよね。

 

今回の記事はそんなディスクレイアウトの常識をAzure上のCentOSを使って

どうレイアウトするかについて少し触れていきたいと思います。

 

まず前提として、Azure内でディスクと呼ばれるものがいくつかありますが

1番わかりやすいものはOSdiskとDataDiskです。

 

OSdiskはその名の通り仮想マシンを払い出した際にデフォで付いているOS

領域のディスクです。CentOS7.xで言うとデフォで30GB割り当てられており

/dev/sdaのデバイスで管理されています。(Azureポータルからこのディスクサイズ

を拡張することもできます:再起動が必要)

DataDiskは追加ディスク領域の部分です。1ディスクあたり最大容量4TBまで指定

でき、/dev/sdc以降のデバイスを基本領域として管理していきます。

 

単に追加分の1ディスクを別マウントポイントとして利用したい場合は以下の記事

を参考にしてください。(ちなみに下の記事ではfdiskを利用していますが、2TB

以上のディスクをフォーマットする際はpartedコマンドでやらないといけません)

 

はじめてのMicrosoft Azure(ディスクアタッチ) - LinuxユーザーがイジるはじめてのAzure

 

もう1つクライアントOSからのマウント、として便利そうなものがAzure File

ストレージ(Azure Files)ですね。

OS内のSMBクライアントから接続することでLinux環境でもマウントして利用

できる共有ストレージです。

 

ここまではおさらいというか基本情報です。やりたいのはここからもう少し

踏み込んだ部分です。

 

上記3つに共通することは、「1つのマウントポイント領域でAzureのディスクを

扱いたい」という点です。ワンエフエス(One File System)は開発者にとっては

楽ちんですからね。いろいろ落とし穴はありそうですが、やってみましょう。

 

では早速Azure Filesからやっていきましょう。

 

まずAzureポータルからStorage AccountのFILEサービスからエンドポイントを確認

し、「+ファイル共有」から1つ作成しましょう。

 

f:id:akazure:20170807163441j:plain

 

作成したファイル共有(ここではlinuxshareという名前)をクリックし、接続を

押下するとLinux環境からマウントするコマンドサンプルが表示されます。便利!

 

f:id:akazure:20170807163758j:plain

 

注記にもありますが、Azure Filesは暗号化対応がまだ未対応のため、異なる

リージョン間でマウント共有することは2017年8月時点ではできません。

 

ちなみにこの東日本で作成したAzure Filesに対して西日本で用意した仮想マシンから

マウントしようとすると以下のエラーがでます。

f:id:akazure:20170807164100j:plain

 

大人しく東日本で作成した仮想マシンから、root権限でマウントしましょう。

また、Azureポータルで表示されているマウント方法はmountコマンドからマウント

するやり方なので、/etc/fstabには以下のように記載しました。

 ※パスワード部分はマスクしているので利用者の環境に合わせてください。

 

# /etc/fstabの追加行(1行)

//centf01stor01.file.core.windows.net/linuxshare        /mnt/azurefiles cifs    vers=3.0,username=centf01stor01,password
=D6v*****Ngtcq/J2s****joeFlkC13qTx/3xqlkaCWF****diseQ==,dir_mode=0777,file_mode=0777,s
ec=ntlmssp

 

ちなみにマウントする前に以下のSMBクライアントを入れておく必要があります。

 

 

yum install -y cifs-utils

 

※CentOS7.3ではデフォで入ってますね 

 

これでmount /mnt/azurefilesとやればきれいにマウントできます。 

折角なので少し大きめのファイル(2GB程度)のものを作成して配置して

みましたが、rmで削除した時に非同期的なな感じになったので共有しておきます。

 

f:id:akazure:20170807164201j:plain

 

見てわかる通りrmコマンドでOS側はプロンプトで返ってきてるが、Azure Files側

ではまだ削除中ステータスのように残っています。5分程放置して見てみると

綺麗になくなっていました。若干Eventually Consistencyな見え方になりますねw

ちなみにmvでファイル移動する際はこのような現象はおきません。

OS内のinodeが変更されるシステムコールは整合性が強いですが、Files内の

ファイルハンドリングだけだとこのような見え方になりそうですね。ま、

結果おーらい。

 

あとリンクファイルの扱いについても注意です。

以下はrsyncで/etc配下を/mnt/azurefilesに同期させた時の結果です。

f:id:akazure:20170807165323j:plain

 

/etc/favicon.pngをコピーする個所でエラーになっています。/etc/favicon.png

シンボリックリンクファイルです。

以下がAzure FilesのREST API referenceになりますが、リンクファイルに対応

するAPIが存在しないため、このようなエラーが出ています。

 

File Service REST API | Microsoft Docs

 

ラージファイルに対する非同期的な動作はまぁよいとして、リンクファイルは

そのままデータ退避・バックアップできない、という点を押さえておくと

よいと思います。もちろんrsyncのオプションに--copy-linksを付けてlink先まで

辿ってリンク元をコピーする、というやり方で回避できますが、あまり実態

ファイルは複数のPATHで持ちたくない場合もありますのでお好みで。

 

また、Azure Filesにファイル数制限はありませんが、全体の容量は5TBまでと

制限があります。同一リージョン内であり、5TB未満の容量でリンクファイル

は扱わない共有ストレージとしての条件であれば超絶便利ですね。

 

はい、Azure Filesはこのへんにしておきます。

以下は5TBの容量では足らないんじゃー、ワンエフエスにこだわりたいんじゃー

という方への参考情報です。

 

f:id:akazure:20170808113709j:plain

 

とりあえず5TB以上なのでDataDiskを4TBx2本、仮想マシンにアタッチしま

しょうか。

ちなみに仮想マシンのサイズ(スペック)によってアタッチできるDataDiskの

本数に制限があります。以下から「Microsoft Azure IaaS リファレンス アーキ

テクチャ ガイド」のPDFをダウンロードして、ご利用されているサイズから

アタッチ可能ディスク本数の制限を確認しておきましょう。

 

Microsoft Azure でシステムを構築する際に参照すべきドキュメント【3/13 更新】 – Microsoft Partner Network ブログ

 

今回試しているサイズはD1ですので2本です。ディスク追加はホットアタッチ

できるので仮想マシンの停止や再起動は不要で楽ですね。

f:id:akazure:20170808135426j:plain

 

はい、OS上でも/dev/sdcと/dev/sddの2つのデバイスが見えました。

ではこの2つの領域をLVMで束ねます。

(mdadmの方が若干性能はでますが、LVMでも大差はないので使い慣れた

 ほうでよいと思います)

 

とりあえずpartedでフォーマットしましょう。

※fdiskは2TB未満のパーティションのみ作成可能なので、今回のように

 2TB以上のパーティション作成にはpartedを利用します。

 

 

parted /dev/sdc

mklabel gpt

mkpart primary 0 4396000

set 1 lvm on

print

quit

 

 

上記は/dev/sdcですが/dev/sddも同様にやります。

次にpvcreate/vgcreate/lvcreateと続けて、1つの論理パーティション

をxfsのファイルシステムとして最大容量の設定します。

ext4でもよいですがCentOS7から標準がxfsになっていますので

それにならいます。

  

pvcreate /dev/sdc1 /dev/sdd1
  Physical volume "/dev/sdc1" successfully created.
  Physical volume "/dev/sdd1" successfully created.

 

vgcreate vg01 /dev/sdc1 /dev/sdd1
  Volume group "vg01" successfully created

 

lvcreate -l 100%FREE -n lv01 vg01
  Logical volume "lv01" created.

 

mkfs.xfs /dev/vg01/lv01

 

mkdir -p /mnt/lvm

 

mount -t xfs /dev/vg01/lv01 /mnt/lvm/

 

こんな感じに見えたでしょうかね。

f:id:akazure:20170808164701j:plain

※今回は手抜きでブロックサイズを指定しませんでしたが、これだけ容量が

 大きいとちゃんと計算してブロックサイズ指定したほうがパフォーマンスは

 出ると思います。

 

永続化は適当に/etc/fstabにUUID登録しといてください。

 

以上ですが、同一リージョン内の同一vNET内でのNFS接続は確認できているので

次回以降どこかの記事で別vNET間のNFSやリージョンまたぎのNFS(お薦めしま

せんがw)なんかを書ければと思いますー。