彷徨うITエンジニアの雑記

ITインフラ関連の雑記とか

NTFSで使用可能なファイル名の文字について

2020/3/26 一部UnicodeのコードポイントとUTF-16エンコードが混在していたので修正しました。

WindowsNTFSは色々な文字をファイル名に使用することができますが、実際どこまで可能なのか試してみました。
とりあえず結果は以下の通りです。

f:id:wandering_engineer:20200326001647j:plain


試した文字の種類は以下の通りです。


途中のUnicodeに関する説明はちょっと自信無いです。Unicode難しい。。。
理解し易いように、文字情報を取得するPowershellの関数を作成しました。

Function Get-CharInfo {
    [string]$char=$Args[0]

    # 文字数を取得
    $char_length=($char | Measure-Object -Character).Characters

    # UFT-16に変換してバイト列を取得
    $char_byte_utf16=[System.Text.Encoding]::BigEndianUnicode.GetBytes($char)
    # UFT-16のバイト列を16進数表示
    $char_hex_utf16=[System.BitConverter]::ToString($char_byte_utf16)
    # UTF-16のバイト数を取得
    $char_byte_count_utf16=$char_byte_utf16.Count

    # UTF8に変換してバイト数を取得
    $char_byte_count_utf8=[System.Text.Encoding]::UTF8.GetByteCount($char)
    # CP932≒S-JISに変換してバイト数を取得
    $char_byte_count_cp932=[System.Text.Encoding]::GetEncoding(932).GetByteCount($char)

    $hash_table=[ordered]@{
        "Character" = $char;
        "Character Length" = $char_length;
        "UTF-16 Bytes(Hex)" = $char_hex_utf16;
        "UTF-16 Byte Count" = $char_byte_count_utf16;
        "UTF8 Byte Count" = $char_byte_count_utf8;
        "CP932 Byte Count" = $char_byte_count_cp932
    }

    return $hash_table

}


シングルバイト文字、2バイト文字

割愛します。

サロゲートペア文字

サロゲートペア文字はUnicodeBMP(Basic Multilingual Plane)に含まれない文字で、4Byte = 16bit(上位サロゲート) + 16bit(下位サロゲート)で構成されます。
Windowsの内部コードはUnicodeのため、文字数的には2文字扱いとなります。
例えば、𠮷(U+20BB7 => 0xD842 + 0xDFB7)、𩸽(U+29E3D => 0xD867 + 0xDE3D)などが該当します。
なお、非常用漢字・旧漢字とUnicode BMPの間に関係性はありません。

PS E:\work> # サロゲートペア文字(ほっけ)
PS E:\work> $char_surrogate='??'
PS E:\work> Get-CharInfo $char_surrogate

Name                           Value
----                           -----
Character                      𩸽
Character Length               2
UTF-16 Bytes(Hex)              D8-67-DE-3D
UTF-16 Byte Count              4
UTF8 Byte Count                4
CP932 Byte Count               2

* Powershellのコンソールはサロゲート非対応なので?に文字化けします。なお、スクリプトから実行する場合はファイルをUTF-8 with BOMで保存する必要があります。

絵文字

大抵の絵文字はUnicodeBMP、またはサロゲートペア文字に含まれます。
ただし、Unicode12.0で追加された絵文字には22バイト=11文字に達するものも存在します。
これはEmoji ZWJ sequenceとして定義されるもので、200Dで複数の絵文字を連結して1個の文字として表現する、らしいです。*1
男性+握手+女性=家族、とか、面白いです。

PS E:\work> # 絵文字(笑顔)
PS E:\work> $char_emoji_smile='??'
PS E:\work> Get-CharInfo $char_emoji_smile

Name                           Value
----                           -----
Character                      😁
Character Length               2
UTF-16 Bytes(Hex)              D8-3D-DE-01
UTF-16 Byte Count              4
UTF8 Byte Count                4
CP932 Byte Count               2


PS E:\work> # 絵文字(家族)
PS E:\work> $char_emoji_family='????????'
PS E:\work> Get-CharInfo $char_emoji_family

Name                           Value
----                           -----
Character                      🧑‍🤝‍🧑
Character Length               8
UTF-16 Bytes(Hex)              D8-3E-DD-D1-20-0D-D8-3E-DD-1D-20-0D-D8-3E-DD-D1
UTF-16 Byte Count              16
UTF8 Byte Count                18
CP932 Byte Count               8


異体字セレクタ(IVS)

異体字は同じ文字でも字形の異なる文字で、基底文字 + 異体字セレクタ(IVS) で表現され、該当の字形がフォントに含まれていれば表示可能です。
IVS自体がサロゲートペアのため、3文字扱いとなります。
例えば、飴(U+98F4)と飴󠄀(U+98F4,U+E0100)などが該当します。
* U+E0100はUnicodeのコードポイントで、UTF-16エンコードは0xDB40(固定値) + 0xDD00(Index) です。

PS E:\work> # 飴の基底文字
PS E:\work> $char_base='飴'
PS E:\work> Get-CharInfo $char_base

Name                           Value
----                           -----
Character                      飴
Character Length               1
UTF-16 Bytes(Hex)              98-F4
UTF-16 Byte Count              2
UTF8 Byte Count                3
CP932 Byte Count               2


PS E:\work> # 飴の異体字
PS E:\work> $char_variant='飴??'
PS E:\work> Get-CharInfo $char_variant

Name                           Value
----                           -----
Character                      飴󠄀
Character Length               3
UTF-16 Bytes(Hex)              98-F4-DB-40-DD-00
UTF-16 Byte Count              6
UTF8 Byte Count                7
CP932 Byte Count               4


合成済み文字、結合文字

合成済み文字と結合文字はUnicodeの正規化の違いです。
Unicodeでは複数の文字を結合して1個の文字を表現することが出来ます。
例えば、"ポ"という文字にはU+30DDが割り当てられていますが、ポ = ホ(U+30DB) + °(U+309A)で表現することも可能です。
前者を合成済み文字、NFC正規化と呼び、WindowsLinux、最近のMacOSで使用されます。
後者を結合文字、NFD正規化と呼び、昔のMacOSで使用されていたようです。結合文字は2文字扱いです。

PS E:\work> # 合成済み文字
PS E:\work> $char_nfc='ポ'
PS E:\work> Get-CharInfo $char_nfc

Name                           Value
----                           -----
Character                      ポ
Character Length               1
UTF-16 Bytes(Hex)              30-DD
UTF-16 Byte Count              2
UTF8 Byte Count                3
CP932 Byte Count               2


PS E:\work> # 結合文字
PS E:\work> $char_nfd=[System.Activator]::CreateInstance([System.String], [char[]]@(0x30db, 0x309a))
PS E:\work> Get-CharInfo $char_nfd

Name                           Value
----                           -----
Character                      ポ
Character Length               2
UTF-16 Bytes(Hex)              30-DB-30-9A
UTF-16 Byte Count              4
UTF8 Byte Count                6
CP932 Byte Count               3



以上です。

CNAMEでSMB共有にアクセスしたい (2/2)

前回の続きです。
wanderingengineer.hatenablog.com

本投稿ではファイルサーバをCNAMEでアクセスさせる際の、具体的な設定手順を解説していきます。

作業環境

ドメイン名 = domain1.local
DNSエイリアス = nas-alias.domain1.local

ホスト名 OS 役割
ad1 Windows Server 2019 ADサーバ、DNSサーバ
nas-real Windows Server 2019 ファイルサーバ
client1 Windows Server 2019 SMBクライアント

DNSサーバにCNAMEレコードを作成する

WindowsDNSマネージャから、ファイルサーバ "nas-real.domain1.local" を参照するCNAMEレコードを作成します。

ファイルサーバのコンピュータアカウントに、DNSエイリアスに対応するSPNを追加する

適当なドメインコンピュータから、Domain Admins権限で setspn コマンドを実行します。
サービスクラスは"HOST"を指定します。
setspn -A HOST/< DNSエイリアス > < ファイルサーバのコンピュータアカウント名 >


* "HOST" は "cifs" を含む複数のクラスのマッピングのようです。*1 動作確認時に問題が発生した場合は "cifs/" のSPNを追加してみてください。


FQDNとホスト名の2個分を登録します。

PS > setspn -A HOST/nas-alias.domain1.local nas-real
ドメイン DC=domain1,DC=local を確認しています

CN=NAS-REAL,CN=Computers,DC=domain1,DC=local の ServicePrincipalNames を登録しています
        HOST/nas-alias.domain1.local
更新されたオブジェクト

PS > setspn -A HOST/NAS-ALIAS nas-real
ドメイン DC=domain1,DC=local を確認しています

CN=NAS-REAL,CN=Computers,DC=domain1,DC=local の ServicePrincipalNames を登録しています
        HOST/NAS-ALIAS
更新されたオブジェクト

SPN追加後のファイルサーバのSPNを確認します。
setspn -L < ファイルサーバのコンピュータアカウント名 >

PS > setspn -L nas-real
次の項目に登録されている CN=NAS-REAL,CN=Computers,DC=domain1,DC=local:
        HOST/NAS-ALIAS
        HOST/nas-alias.domain1.local
        WSMAN/NAS-ALIAS
        TERMSRV/NAS-ALIAS
        RestrictedKrbHost/NAS-ALIAS
        WSMAN/nas-real
        WSMAN/nas-real.domain1.local
        TERMSRV/nas-real
        TERMSRV/nas-real.domain1.local
        RestrictedKrbHost/nas-real
        HOST/nas-real
        RestrictedKrbHost/nas-real.domain1.local
        HOST/nas-real.domain1.local

"SPNターゲット名検証レベル"をオフに設定する

ADサーバでポリシーの結果セットを出力して、該当ポリシーが"未実装"または"オフ"になっていることを確認します。

f:id:wandering_engineer:20200223000358p:plain


またはファイルサーバと適当なクライアント上で、レジストリの SmbServerNameHardeningLevel の値が"0"になっていることを確認します。

PS > Get-ItemProperty -PATH "Registry::HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" -Name SmbServerNameHardeningLevel


SmbServerNameHardeningLevel : 0
PSPath                      : Microsoft.PowerShell.Core\Registry::HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\P
                              arameters
PSParentPath                : Microsoft.PowerShell.Core\Registry::HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer
PSChildName                 : Parameters
PSProvider                  : Microsoft.PowerShell.Core\Registry

DNSエイリアスをファイルサーバの代替名として登録する(Windowsのみ)


*この手順はWindowsベースのファイルサーバのみ実施します。アプライアンスNASについては、類似の対応が必要か個別に確認してください。


ファイルサーバにログインし、Domain Admin権限で netdom コマンドを実行します。
netdom computername $(hostname) /add:< DNSエイリアス >

PS > netdom computername $(hostname) /add:nas-alias.domain1.local
nas-alias.domain1.local をコンピューターの代替名として
正常に追加しました。

コマンドは正しく完了しました。

登録されている全てのホスト名を表示し、DNSエイリアスが追加されていることを確認します。
netdom computername $(hostname) /Enumerate

PS > netdom computername $(hostname) /Enumerate
コンピューターのすべての名前:

nas-real.domain1.local
nas-alias.domain1.local
コマンドは正しく完了しました。

念のためWindowsを再起動しておきます。

接続確認(Kerberos認証)

ドメインユーザでSMBクライアントにログインし、キャッシュされているサービスチケットを削除します。

PS > klist purge

現在のログオン ID: 0:0x77438
        すべてのチケットを削除しています:
        チケットが削除されました。

DNSエイリアスでUNCパスを指定し、共有を参照できること、サービスチケットをキャッシュ出来ていることを確認します。
"net use"コマンドの場合はNTLM認証が使用されたので、エクスプローラか、"Get-ChildItem"コマンドを使用してください。
キャッシュされたチケットは"klist tickets"で確認できます。

PS > Get-ChildItem -Directory -Path \\nas-alias.domain1.local\project


    ディレクトリ: \\nas-alias.domain1.local\project


 Mode                LastWriteTime         Length Name
 ----                -------------         ------ ----
 d-----        2/21/2020   5:04 PM                プロジェクトフォルダ1

PS > klist tickets
...
#1>     クライアント: administrator @ DOMAIN1.LOCAL
        サーバー: cifs/nas-alias.domain1.local @ DOMAIN1.LOCAL
        Kerberos チケットの暗号化の種類: AES-256-CTS-HMAC-SHA1-96
        チケットのフラグ 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        開始時刻: 2/23/2020 0:40:48 (ローカル)
        終了時刻: 2/23/2020 10:40:48 (ローカル)
        更新期限: 3/1/2020 0:40:48 (ローカル)
        セッション キーの種類: AES-256-CTS-HMAC-SHA1-96
        キャッシュ フラグ: 0
        呼び出された Kdc: ad1.domain1.local

接続確認(NTLM認証)

ローカルユーザでSMBクライアントにログインします。
エクスプローラか"net use"コマンドを使用し、アクセス権を有するドメインユーザで共有を参照します。
DNSエイリアスでUNCパスを指定し、共有を参照できること、サービスチケットをキャッシュしていないことを確認します。

PS > net use z: \\nas-alias.domain1.local\project /user:domain1\administrator
コマンドは正常に終了しました。

PS > Get-ChildItem -Directory -Path Z:


    ディレクトリ: Z:\


 Mode                LastWriteTime         Length Name
 ----                -------------         ------ ----
 d-----        2/21/2020   5:04 PM                プロジェクトフォルダ1


PS > klist tickets

現在のログオン ID: 0:0x965de5

キャッシュされたチケット: (0)


以上です。




参考にした情報:
Using Computer Name Aliases in place of DNS CNAME Records - Microsoft Tech Community - 259064
The service principal name (SPN) target name validation level will be turned off.

CNAMEでSMB共有にアクセスしたい (1/2)

CNAMEを使用してDNSエイリアスでファイルサーバにアクセスさせたい、という要求があると思います。
レプリケーション構成でプライマリ・セカンダリを切り替え運用する場合、リプレース時に既存ファイルサーバの名前を維持したい、等。
単純にファイルサーバを参照するCNAMEを設定しても、アクセスが通る場合、通らない場合があり、本投稿はその辺を調査・解説した内容となります。


前提としてクライアント、ファイルサーバは同一ドメインに所属しているものとします。
クライアントがファイルサーバに対しSMBアクセスする際の、正常なKerberos認証のフローは以下の通りです。
 

  1. クライアントはADサーバ(KDC)からTGT(Ticket to Get Ticket)を取得する
  2. クライアントはKDCに対しTGTとファイルサーバのSPN(Service Principal Name)を送信し、ファイルサーバのサービス鍵で暗号化されたサービスチケットを取得する
  3. クライアントはファイルサーバに対しサービスチケットを送信する
  4. ファイルサーバは自分のサービス鍵でチケットを複合化・検証し、クライアントを認証する


SPNは <クラス>/<ホスト名> @ <レルム> で指定され、SMBアクセスならcifs/nas-real.domain1.local @ DOMAIN1.LOCAL等になります。
SPNはドメインのコンピュータアカウントに紐づきますが、ホストのドメイン参加時にADサーバ上に自動作成されます。

コンピュータアカウントのSPNは setspn コマンドで確認可能です。

PS > setspn -L nas-real
次の項目に登録されている CN=nas-real,CN=Computers,DC=domain1,DC=local:
WSMAN/nas-real
WSMAN/nas-real.domain1.local
TERMSRV/nas-real
TERMSRV/nas-real.domain1.local
RestrictedKrbHost/nas-real
HOST/nas-real
RestrictedKrbHost/nas-real.domain1.local
HOST/nas-real.domain1.local

 
要求したSPNがKDCに存在しない場合、KRB_ERR_S_PRINCIPAL_UNKNOWN が返され、クライアントはサービスチケットを取得できません。
CNAMEを作成しただけでは、DNSエイリアスに対応するSPNcifs/dns-alias @ REALMが存在しないため、この状況が発生します。
そして、サービスチケットを入手出来なかったクライアントは、Kerberos認証からNTLM認証へフォールバックします。
NTLM認証が実行される条件としては他に、DNSベースでなくIPアドレスベースのアクセスが該当します。*1

上記より、CNAMEのみ登録した状態で、DNSエイリアスによるNASへのアクセスが成功するケースでは、NTLM認証が実行されていると推測できます。

クライアントがDNSエイリアスに対応するサービスチケットをキャッシュ出来ていないのにアクセスに成功していれば、NTLM認証です。

Windowsクライアントでキャッシュ済みのサービスチケットを確認するには、klist コマンドを使用します。

PS > klist tickets
...
#2>     クライアント: administrator @ DOMAIN1.LOCAL
        サーバー: cifs/nas-real.domain1.local @ DOMAIN1.LOCAL
        Kerberos チケットの暗号化の種類: AES-256-CTS-HMAC-SHA1-96
        チケットのフラグ 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        開始時刻: 2/22/2020 18:22:09 (ローカル)
        終了時刻: 2/23/2020 4:18:43 (ローカル)
        更新期限: 2/29/2020 18:18:43 (ローカル)
        セッション キーの種類: AES-256-CTS-HMAC-SHA1-96
        キャッシュ フラグ: 0
        呼び出された Kdc: ad1.domain1.local

またはパケットをトレースするか、Windowsファイルサーバであればイベントログの4624からも判断できます。

Kerberos認証成功時のイベントログ:

...
ネットワーク情報:
	ワークステーション名:	-
	ソース ネットワーク アドレス:	10.10.1.100
	ソース ポート:		50120

詳細な認証情報:
	ログオン プロセス:		Kerberos
	認証パッケージ:	Kerberos
	移行されたサービス:	-
	パッケージ名 (NTLM のみ):	-
	キーの長さ:		0
...

NTLM認証成功時のイベントログ:

...
ネットワーク情報:
	ワークステーション名:	client1
	ソース ネットワーク アドレス:	10.10.1.121
	ソース ポート:		51983

詳細な認証情報:
	ログオン プロセス:		NtLmSsp 
	認証パッケージ:	NTLM
	移行されたサービス:	-
	パッケージ名 (NTLM のみ):	NTLM V2
	キーの長さ:		128
...


なお、WindowsにはサーバSPNターゲット名検証レベルという設定が存在します。*2
デフォルト無効ですが、有効の場合は必要と思われるSPNが登録されていても、DNSエイリアスでSMBアクセスした際に認証ダイアログが表示されて、さらに認証エラーとなりました。

f:id:wandering_engineer:20200222203424p:plain


よって、DNSエイリアスによるアクセスでKerberos認証をパスするには、以下の条件を満たしていれば良さそうです。

  • サーバ・クライアント間でSPNターゲット名の検証がオフになっている
  • ファイルサーバのコンピュータアカウントに、DNSエイリアスに対応するSPNが追加されている

ちなみに、AD上に手動でDNSエイリアス名のコンピュータアカウントを作成し、それにSPNを設定してみましたが動作しませんでした。
多分、サービスチケットの取得か複合化に失敗しているからだと思われます。(未調査)
NASリプレース時、旧NASのホスト名を引き継ごうとしてCNAME追加後に認証エラーとなるパターンも類似の事象で、旧NASのコンピュータアカウントとSPNがまだ存在している場合に、新NASが旧NASのサービス鍵で暗号化されたチケットの複合化に失敗しているのだと推測されます。


また、IPアドレスベース、非ドメインのホストからのアクセス(NTLM認証)を想定し、以下を実行しておくと良さそうです。

  • ファイルサーバ上で、代替ホスト名としてDNSエイリアスを追加する(Windowsファイルサーバのみ)

ファイルサーバ上で レジストリキー DisableStrictNameChecking の値を変更する方法が伝統のようですが、セキュリティリスクより代替ホスト名を設定した方が良いとのこと。*3


具体的な設定手順は、次の投稿で解説します。



参考にした情報:
[Active Directory] Kerberos 認証について調べてみた件 | インフラSEの運用・構築メモ
https://support.microsoft.com/en-us/help/3181029/smb-file-server-share-access-is-unsuccessful-through-dns-cname-alias
ストレージコントローラの正しい SPN を設定する方法

Windows 10 でヘッドセットが使えなくなった場合のTIPS

Web会議中にヘッドセットのバッテリーが切れて、別のヘッドセットに切り替えた時に、マイクが音拾わないンゴ、、、。

って状況になって焦ったので自分用メモ。

 

Web会議アプリを終了する

自分がミーティング主催者の場合は別の参加者に委任してから終了すること。

トレイに常駐しているプロセスも落とす。

ZoomとSkypeとか、ヘッドセットを掴んでいそうなアプリが複数起動してるなら全て落とす。

大抵これで解決する。

 

ヘッドセットの再登録

1. [コントロールパネル] => [デバイスとプリンター] => リストからヘッドセットを削除する。

f:id:wandering_engineer:20200220194720p:plain

 

2. ヘッドセットをペアリングモードに遷移する

Jabra 65t:右のファンクションボタンを5秒以上長押し

Jabra 75t:左右のボタンを同時に長押し

Plantronics Voyager Legend:音声ボタン(マイクの端のボタン)を長押し

Bose SoundLink:電源ボタンをOFFからONの状態を数秒維持

 

3. [デバイスの追加]をクリックしてヘッドセットを再登録する。

 

4. デバイスを右クリック => [サウンドの設定] => [再生]

既定のデバイス:ヘッドホン

既定の通信デバイス:ヘッドセット

となっていればOK。そうでないなら右クリックから設定。

f:id:wandering_engineer:20200220200041p:plain

 

 5. デバイスを右クリック => [サウンドの設定] => [録音]

既定のデバイス:ヘッドセット

またこのとき声を出して、右横のインジケーターが反応すればOK。

f:id:wandering_engineer:20200220200141p:plain


6. アプリを起動し、オーディオ設定でマイク、スピーカーの両方を「ヘッドセット(既定の通信デバイス)」にセットして音声テストする。

f:id:wandering_engineer:20200220202805p:plain



 

 

 

日本国内で購入可能な企業向けファイルサーバについてまとめてみた

2019年12月現在、日本国内のリセラーから購入可能なファイルサーバについてまとめてみました。

職務的に情報量に偏りがあるのは許してほしい。

 

 

ターゲット

この記事は組織のIT担当者で、ファイルサーバの導入・リプレースを検討している人を対象としています。

HA必須、Windows Server等の汎用OSは除外、イニシャルX00万円以上を想定しています。

最近のエンタープライズ向けNASはその機能に大差はないため機能比較はしません。ただしアーキテクチャや機能の実装方式は異なるし、サポートされる機能にも制限事項が存在します。詳細は取り扱いベンダやメーカーに確認して下さい。

この記事が情報収集のとっかかりにでもなればと思って書いています。

 

用途

NASといっても様々ですが、この記事では一般的な企業向けファイルサーバに限定します。

  • Officeドキュメント等を保存する社員向けのファイルサーバ
  • ホームディレクトリ、ユーザプロファイル置き場

 

HPC、メディア、ヘルスケア、仮想化等、特定用途向けのストレージを探している人は、対象システムの構築を生業としているベンダから情報収集することをお勧めします。

 

アプライアンス型とSDS型(Software Difined Storage)

 

アプライアンスは専用ハードウェアとストレージOSをセットで提供するタイプ。 めっちゃ寡占状態。最近はvSphereやパブリッククラウド向けに仮想アプライアンスを提供するようになった。メインはオンプレ&ハードウェアで、レプリケーション先は仮想アプライアンスで、みたいな使い方が多いと思います。

 

メリット

  • ハードウェアとストレージOSのコンパチビリティを考慮する必要が無い
  • 専用ハードウェア向けにチューニング済み(安定性・パフォーマンス)
  • サイジングが簡単。大抵、専用のサイジングツールが提供されている。
  • 保守が1本化される。トラブルが発生しても原因調査から解決法の提示までスムーズに進むことが多い。

 

デメリット

  • 構成の自由度が低い
  • 保守・増設コストが高くなりがち(イニシャルは結構下がるケースが多いので、最初からオーバーサイズで購入した方が安かったりする)

 

SDSは汎用サーバにインストール可能なストレージOSのみを提供するタイプ。ただし複数のサーバメーカー等とパートナー契約し、テスト済みのサーバにソフトを乗せてアプライアンス提供しているケースも多い。

 

メリット

  • システム要件にあったハード構成を組むことが出来る、逆にハードの設計が必要とも言える
  • メモリやCPUなどパーツ単位の増設が可能
  • 大人の事情で購入するハードウェアメーカーが限定されるケースに対応できる(コンパチビリティリストは遵守しよう)
  • アプライアンス提供の場合はテスト済みのハードウェアで提供されるため、コンパチビリティテストを省略できる
  • アプライアンスなら保守窓口をハードメーカーに1本化出来るケースもある

 

デメリット

  • ハードとソフトで保守が分かれている場合、障害発生時にハードメーカーとSDSメーカーをたらい回しにされる可能性がある
  • さらにハードウェアのファームェアに起因する障害だった場合、修正版が存在しないとユーザー負担で代替品を調達するしかないかもしれない。コワイ!!
  • なので、SDSの場合もアプライアンス推奨だが、構成の自由度は低くなる

 

スケールアップ型とスケールアウト型

スケールアップ型はコントローラとバックエンドストレージから構成されます。コントローラは大抵2ノードのHA構成で、ファイルシステム、CIFS/NFSサービス、クラスタリング機能、等を実行します。

  

f:id:wandering_engineer:20191230093755p:plain

 

ディスクを増設する場合は空きスロットにディスクを追加するか、ディスクエンクロージャを追加します。コントローラ性能を増強する場合はCPUやメモリを増強するか、上位モデルに交換する必要があります。

スケールアップ型を選択する場合は、リソースのフォーキャストとハードウェア構成の上限を考慮する必要があります。構成の上限に達した場合は新たにNASを調達し、クライアントアクセスを分散しなくてはなりません。ファイルサーバの乱立、サイロ化とか言われているのはこのことです。

 

スケールアウト型は複数のストレージノードが単一のクラスタを構成します。コントローラ機能とディスクを搭載したストレージノードをノード間通信用ファブリックに追加していくことで、ディスクとコントローラを同時に拡張することが出来ます。

 

f:id:wandering_engineer:20191230101638p:plain

 

スケールアウト型の構成の上限はクラスタの最大ノード数になります。

大規模環境や、将来の要求リソースの予測が付きにくいシステムなどにマッチし易いソリューションです。

 

アプライアンス NAS製品の紹介

 

NetApp FAS/AFF

所謂アプライアンスNASと定義されるものを初めて世に送り出したメーカーです。NAS専業(最近はHCIもやってる)25年以上の超老舗。

モデルはSSD、HDDのハイブリッド構成可能なFASシリーズと、オールフラッシュのAFFシリーズを提供を提供しています。エントリーからハイエンドまで対応可能です。スケールアウト可能ですが、2コントローラ構成のスケールアップ型として導入される事例が殆どだと思います。

一貫してONTAPと呼ばれるストレージ専用OSを採用していますが、スケールアウトに対応するため、2004年にSpinnaker Networksを買収しコードの大規模な書き直しを行っています。現行バージョンはONTAP9.6となっています。

仮想アプライアンスはvSphere版とAWS/Azure/GPC版が提供されていて、複数のプラットフォーム間で連携可能です。

長年の蓄積があるため、NASに関してNetAppで出来ないことはほぼないと言ってもいいくらい多機能ですが、シンクラ界の老舗のCitrix製品と同じくパラメータがすげー多いのが難点。設計構築は導入経験豊富なベンダに依頼しましょう。

その他の大きな特徴はWAFL呼ばれるファイルシステムで、メモリ上でランダムI/OをHDDに有利なシーケンシャルI/Oに変換してからフラッシュします。WAFLはポインターベースのスナップショットにより、データ書き換え時の性能劣化がほぼ発生しません。ボリュームレベルのリストアも非常に高速です。

I/Oのシーケンシャル化や、Redirect-on-Write(RoW)と呼ばれるスナップショット方式は現在では複数のベンダが採用していますが、WAFLとして特許を取得したのはNetApp社です。*1

アーキテクチャは若干レガシーだが枯れている分、安定性は断トツだと思います。運用開始後のトラブルはかなり少ない印象。

 

Dell EMC Unity

2016年にDellに買収されましたが、EMCもストレージ界の老舗です。Unityは旧EMC VNXの後継シリーズ。

現行は第3世代のUnity XTシリーズで、NetApp同様ハイブリッドモデルとオールフラッシュモデルが提供されています。エントリーからミッドレンジに対応。分類としてはスケールアップ型NASとなります。

Operation Environment (OE)と呼ばれるストレージ専用OSを全モデルで採用していて、現行バージョンはOE5.0となっています。

仮想アプライアンスはvSphere版とVMware Cloud on AWS版が提供されています。EC2ネイティブ、その他パブリッククラウドは非対応。VMwareDell傘下だからね、仕方ないね。

設計が新しい故か、NetAppとは逆にパラメータが少ないです。設計から担当するなら勉強して資格取った方がいいと思いますが、セットアップだけなら多分1日程度のトレーニングで足りてしまいます。細かい設定が出来ない分、「仕様」で済ませられるのは大きいです。

スナップショットはNetApp同様RoWのためパフォーマンス劣化は発生しません。

その他NetAppに無い特徴として、オールフラッシュモデルのみ、ディスクをチャンクレット単位に分割してプール化するDynamic Poolを採用しています。これは3PARやDeclustered Raidと同様の方式で、筐体内のすべてのディスクにI/Oを分散させることが出来るため、I/Oの高速化、リビルド時間の短縮、専用スペアディスクの排除を実現します。SSDの増設が1本単位で可能という点も大きなメリットと言えます。

 

Dell EMC isilon

Isilon Systemsは独立ストレージメーカーでしたが、2010年にEMCに買収されました。

現行は第6世代で、オールフラッシュ、ハイブリッド、アーカイブ向けのモデルを提供しています。ミッドレンジからハイエンドに対応。スケールアウトと言えばisilonというくらいスケールアウトNASの代表格で、クラスタあたり最大252ノード、66PBまで拡張可能です。

OneFSと呼ばれるFreeBSDベースのストレージ専用OSを全モデルで採用していて、現行バージョンはOneFS8.2となっています。

isilonは筐体内でRaidを実行せず、ノードレベルでデータを分散配置&Erasure Codingによるデータ保護を実行します。ファイルを128KBに分割し、ノードレベルでデータをストライプ、FEC(前方誤り訂正)を追加することでN+Mの保護レベルを実現しています。

メディア系等、大きなサイズのファイルの格納に適したアーキテクチャですが、一般的なファイルサーバとしても多数導入されています。最近のバージョンでは、オーバーヘッドが大きいスモールファイルを効率的にアーカイブするCompaction機能もサポートされました。

スナップショットはNetApp同様RoWのためパフォーマンス劣化は発生しません。

また、isilonの特徴としてユーザビリティが上げられます。クラスタ全体で単一のファイルシステムを構成し、シングルネームスペースを提供するためボリューム構成で悩む必要は無く、保護レベルやスナップショットはディレクトリレベルで設定出来ます。またクォータも非常に柔軟で、ネストや容量監視のみのクォータ設定が可能です。

拡張はGen6の場合2ノード単位の追加、ディスクはフル搭載が条件となっています。予算確保に時間がかかる組織で導入する場合は、リソースのフォーキャストを得るためIngishtIQ等、分析ツールの導入を推奨します。というかどのストレージを購入するにしろ、純正の分析ツールは導入して欲しい。

  

SD NAS製品の紹介

Nexenta NexentaStore

OpenSolarisカーネルフォークであるillumosをベースとした、ストレージ専用OSのディストリビューションNexenta Systemsが商用提供していましたが、2019年にHPC系のDataDiect Networksに買収されました。

Solarisの成果であるZFSを使用するのが最大の特徴で、シンプロビジョニング、スナップショット、クォータ、レプリケーションSSDキャッシュ、暗号化等、エンタープライズNASに必要な機能はほぼ網羅しています。

逆にZFSといえばファイル削除が遅いとか、スナップショットがCoWだからI/O負荷が大きいとか、重複排除が重いとか言われていますが、オールフラッシュ構成にしたりメモリ増強で回避出来るケースもあります。ノウハウのあるベンダにハードウェアサイジングと構築を依頼すれば、パフォーマンス問題は回避出来ると思われます。

Nexenta公式サイトからDell、HPE、Supermicroのサーバを使用したリファレンスアーキテクチャが公開されています。*2

国内ではコアマイクロシステムズが自社ブランドのストレージサーバを、アセンテックがLenovoサーバベースのアプライアンスを販売しています。国内ではコアマイクロ社が一番ノウハウを持っていると聞いたことがあります。

分類としてはスケールアップ型NASで、エントリーからミッドレンジまでカバーできると思われます。

HAクラスタを構成する場合はSAN接続の共有ディスクが必要ですが、マルチノードサーバを使用するとアプライアンスっぽくコンパクトに収まります。

 

Qumulo

旧isilonのメンバーらが2012年に立ち上げたSDSメーカーです。

スケールアウト型NASで、シングルネームスペースの提供、Erasure Codingによるデータ保護など、SDS版isilonと言っていいかと。コマンドラインもisilonに似てます。

Qumulo Filesystemと呼ばれるファイルシステムがコアテクノロジーで、フラッシュデバイスを前提としたモダンな設計思想となっています。

isilonはファイルを128KBのチャンクレットに分割しデータ保護を実行していますが、Qumuloはブロックレベルでデータ保護を実行しており、4KBブロックによるアドレス管理・セグメンテーション・エンコーディングを採用しています。スモールファイルについてisilonより容量効率が良く、リビルドも高速、様々なワークロードに対応可能と言われています。*3

またファイルシステムに分析エンジンが統合されているのも特徴で、リアルタイムに容量・パフォーマンス分析を実行可能です。

ハードウェアはオールフラッシュ、ハイブリッドモデルがQumuloブランドで提供されていますが、2019年現在国内のリセラーは存在しません。

ただしHPE Apollo 4200、Dell EMC RX740xdにQumuloのソフトウェアを組み込んだアプライアンスが提供されていて、少なくともHPEモデルは国内で購入可能となっています。ノードあたり90TBからなので、isilon同様ミッドレンジからハイエンド相当の製品です。*4

 

Datacore vFilo

SDS老舗のDatacore社が、2019年11月にリリースしたばかりの製品です。

同社はSANsymphonyというWindowsベースのFC/iSCSIストレージを長年提供してきましたが、vFiloはストレージ専用OSにて提供されるNAS製品となっています。

現状まともな情報ソースは公式のインストールガイドと、ジャパンの中の人Qiita投稿くらいしかないです。*5

以下は流し読みした内容。

スケールアウト型のSDS NASで、メタデータノードのAnvil、データノードのDSXから構成されます。メタデータとデータが分離している辺りはLustreっぽい。リアルタイム分析等の機能追加を見越してメタデータを分離しているのかもしれないです。

インストール先はベアメタル、またはvSphereをサポートしています。

Anvilは共有ストレージレスのHA構成が可能です。

DSX部分がスケールアウト可能で、データレイアウトはStripingとMirroringが選べるようです。SimplivityのようにハードウェアRaidと併用する前提と思われます。

DSXは外部のNFSストレージ、AWS/Azure/GCPのオブジェクトストレージに対するゲートウェイ(Mover)としても機能します。

HAで最小4ノード構成ですが、ディスク構成は自由に決められそうなのでエントリークラスとしても導入できそう。

Audit、ユーザクォータは未実装ぽい。グローバルネームペース、暗号化、重複排除・圧縮、S3互換プロトコルはComing soonになっていました。

機能はまだ足りないし検証してみないと何とも言えませんが、NASの選択肢が増えたことは素直に歓迎したいです。