KuriKumaChan’s diary

Kuri ちゃんと Kuma ちゃんの飼い主の独り言

IIJ のデータシェア機能が 06/01 から提供開始 - さっそく準備として eSIM 以外を最低の 2GB プランに変更した

6月提供予定となっていた IIJ のデータシェア機能が月初の 6月1日から利用できるようになると発表がありましたので、その準備でちょっとしたプランの変更を予約しました。

f:id:KuriKumaChan:20210525214429p:plain
今日 (2021/05/25) の IIJ の発表

www.iijmio.jp

blog0.kurikumachan.com


データシェア機能とは?

上記の IIJ の発表記事によると、どうやら正式名称は「データ容量シェア機能」と呼ぶらしいです。これは「同一契約(同一ID)で保有する複数回線間でのデータ容量のシェア」ができるというもので、私のように一つの契約のもと複数の(私は 3回線の)契約を持っている人にはお得な機能です。もちろん他にも色々な新機能が提供開始となり、「5Gオプション(無料❗️)」や「ガプラン専用の追加データ量(クーポン)」等々も始まるようですが、複数回線持ちの人にとってはこのデータシェア機能が一番メリットの大きい機能だと思います。

www.iijmio.jp

f:id:KuriKumaChan:20210525223238p:plain
契約容量が大きいほど、また SIM 種類によってギガ単価が大きく変わる。

おそらく他のキャリアも全て同じだと思いますが、契約容量が大きいほどギガ単価が下がります。
2G > 4G > 8G > 15GB > 20GB
また SIM 種類によってもギガ単価が下がります。
音声 SIM > SMS SIM > データ SIM > eSIM
ギガ単価が異なる回線を同一 ID のもとデータシェアできるということは、当たり前のことですが最低ギガ単価の回線で必要な容量を契約し、他の回線は最小容量の契約とする、のがベストです

ギガ単価の高い音声 SIM を最小容量の 2GB に変更する。

現在の私の保有 4回線は、

  • iPhone 11 Pro [メイン(通話, LINE, 電子マネー..)] - IIJ <タイプD> ギガプラン4GB + 楽天モバイル eSIM

  • Pixel 5 [ポケモン & 予備] - IIJ (タイプA)ギガプラン2GB

  • iPad Pro [RSS リーダー & twitter] - IIJ eSIMギガプラン8GB

となっています。このギガプラン4GBを 2GB に変更予約しました。

f:id:KuriKumaChan:20210525222335p:plain
現状のプランと選択した新しいプランがわかりやすく表示されるようになりました。

f:id:KuriKumaChan:20210525222535p:plain
毎月 200円の削減に。

今までも必要に応じて IIJ のプランは何回も変更してきたのですが、今回プラン変更の UI が刷新されてかなり分かりやすいものとなりました。IIJ は以前も今回もシンプルに表現することをベースとしているようですが、今回は視覚的な工夫で「変更するプラン」と「変更後のプラン」が対比されるようになって(私よりも)お年を召した方にも理解しやすいのではないかと思いました。この辺りはメガキャリアとは一線を画すポリシーなんでしょうね。応援したくなるポイントです。
しかし、こう分かりやすくプランを設定してしまうと IIJ 側としては収益の低下につながるのは避けられないのはわかった上での対応なのでしょうね。


というわけで、6月からの契約準備完了です!

f:id:KuriKumaChan:20210525223803p:plain
私には 19GB も不要

QNAP 自分のためのヒントメモ

同じことを何回も調べなおしたり戸惑ったこと。

QTS 表示言語の設定

QNAP Support に情報提供する際など日本語表示のままだと通じないので英語表示に変更した上で画面キャプチャーなどしたい。
➡︎ QTS 右上 ドットから「言語」を選択

  • いつでも言語表示切り替え可能。特に再ログオンなども不要。

HBS3 ジョブ設定に関するチュートリアル

www.qnap.com.cn

ログのzipファイルへのダウンロード

QNAP Support に添付するログファイルの取得方法。
「ヘルプセンター」アイコン
→ ヘルプデスク → 診断ツール → ダウンロードログ

ダウンロードログ

HBS3 Debug report

HBS3 に関わるログ等の取得方法

  • ジョブ実行時には取得できない。

How do I collect the debug logs from HBS3 and all the necessary information to send for analysis? | QNAP (IN)

サービスポータルへのアクセス

正式名称が不明だが、以下の流れでログインの上自分のチケットにアクセスできる。
ホームページ → サポート → テクニカルサポート →
サービスポータルにサインイン →
(マイデバイスの右の)サポート

HBS3 restore to "Source:Backup Job" & "Original location" が実行できる条件

❌(1)Backup と同じ volume 名がバックアップ先に存在する(だけ)
⭕️(2)Backup と同じ (volume 名と)フォルダー名がバックアップ先に存在する (1) の場合は以下のエラーメッセーが QTS に表示

Error 2021-05-30 18:31:45 admin 127.0.0.1 Hybrid Backup Sync Job Status [Hybrid Backup Sync] Failed to complete Restore job: "Restore 1989F_89001". Folder pairs are invalid or inaccessible. Error code: -50

QNAP NAS の ボリュームタイプ変更 (2) - 自分にとってより良い構成は?

前回の整理として、以下のようなまとめをしてみました。

  1. ストレージプールを設定するか否かがスペース効率と各種機能利用の分かれ道

  2. 最高速の static と Thick を比較してもキャッシュ利用の元では体感するような差は無い

その前提で今回は自分の環境を見直して困っていることは何か?新しい構成をどうしようか考えてみることにします。


現状困っているのは?

二つのボリュームに空き容量の差

TS-431p の頃から二つの RAID グループに分けてそれぞれにボリュームを配置する方法でやってきました。

二つの RAID グループに static volume と storage pool/Thick volume を作成

現在は全ての HDD に 3TB のものを使用しているので、トータルで 6TB の容量があります。しかし二つのボリュームを個別に見てみると、写真データを保存しているボリューム (Datavol2) はデジカメ撮影が減ってもフィルム写真のデジタル化を始めたため(最近は停滞気味ですが..)順調に容量は増え使用率も 70% を超えてきました(1.9TB/2.67TB, TiB 換算)。 一方の CD 等音源データを中心としたボリューム (Datavol1) はもちろん容量は増えていますがデジタル写真データほどではありません(50.6% 1.32/2.61TB TiB 換算)。Datavol1 の空き容量をデジカメデータ用 (Datavol2) に振り向けてあげられたらいいなとは思いますが、現状の構成(一方が static、もう一方が Storage pool 設定で Thick)ではそれはできません

やはりストレージプールの柔軟性を享受したい

今回はたまたま Yahoo ポイントがだいぶ溜まっていたので奮発して 8TB の HDD を購入しましたので極端な話をすれば今まで通り Static volume のままでも今は一向に困らないのですが、将来に備えてそれとやっぱり興味を持った時にチャレンジするのが良いと思い全 HDD/RAID を一つのストレージプールに構成することにしてスペース効率に柔軟性を確保したいと思いました。

Wedtern Digital の RED に "Pro" と ”Plus” が!何が違うのか?

横道にそれますが、ここ数年は WD の RED シリーズの HDD を使っています。売り文句が「NAS に最適」なのでそれを鵜呑みにしているだけですが、確かに最初に TS-431p で使い始めたのだと思いますが故障は一回も無かったのでは無いかと思います(手元にある壊れた/不要な HDD の山の中に RED は無いので)。
今回も RED を買うつもりだったのですが、カートに入れたのが "RED Plus"。そういえば "RED Pro" というのは以前から認識はしていたのですが、Plus は初めてみました。
何が違うかというと、円盤(プラッタ)への記録方式の違いだとか。RED が "SMR(Shingled Magnetic Recording)"、RED Plus が "CMR(Conventional Magnetic Recording)" だとのこと。
正直その違いはよく分かりません。私が買った時はカートに入れた後に "RED" と値段を比較してもさほど変わらなかったのでそのまま購入しました。正直なところキャッシュもあるし "RED" で今まで何も不自由していなかったのですが。。。
具体的な 無印, Pro, Plus の違いを確認したい方には下記の記事を紹介しておきます。

“NAS向けHDDはCMR”のコダワリ派も納得。「WD Red Plus」実力検証!CMRとSMRの違いも教えます!! - AKIBA PC Hotline!

WD Redシリーズの特長とは?色ごとの違いを知って最適な製品を選ぼう | 分かりやすく解説!HDD・SSD!!

ストレージプールのイメージ図

私なりに NAS のレイヤーを図にしてみました(下図)。これは一台の NAS の内容を書いたものではなく、HDD、RAID、ストレージプール、ボリュームのレイヤーを描くために多くの HDD を横並びに並べています。
一番左の vol.A は RAID すら構成しない HDD をそのまま共有ボリュームに設定する一番シンプルなイメージです(そんな構成をする人はいないと思いますが)。
赤点線で囲んだ vol. B, C が現在の私の構成です。せっかくストレージプールをひとつ構成していますが、ひとつの RAID に占有的に設定しているのでストレージプールのメリットであるスペースの柔軟性は皆無で RAID の容量がストレージプールの容量(つまりボリュームの最大容量)になっています。これでは図の左側の vol. B (ストレージプールのない static volume) とほとんど変わりません。

もちろん単なるボリューム作成の柔軟さという観点では、一つの RAID にだけマッピングされたストレージプル 2 であっても、そこに複数のボリュームを配置することは可能なのですが、現状の私のストレージプールには十分な空きスペースはありませんし、新たなボリュームを必要とするニーズも今はありません。
やはり、ストレージプールを活用するのであれば、ストレージプール 3 のように複数 RAID の上に構成して最大限のスペースを利用可能とし、その上でボリュームは RAID 容量を一切意識せずにストレージプール内に配置したいものです。実際にそこまで必要かどうかは別にして、Thin volume にすればストレージプールの容量さえ超える容量のボリュームさえ作成できます("thin provisioning", "over-allocation")。

Storage pool をドライブ/RAID を跨いで設定することで柔軟なボリューム構成が可能になる

私の場合の構成案

と言うわけで、上の図のように沢山の HDD は無い 4ドライブの私の TS-453Be の場合は以下のようにしてみたいと思います。 ポイントは二つです。

  • ストレージプール二つの RAID を含むストレージプールを構成する ➡️ 個々の RAID 容量を気にしなくて良くなる!

  • ボリューム:二つのボリュームはストレージプールに柔軟に配置する(Thick, Thin は後で考える。双方向の変換も可能)

下図で現状と構成案の比較をまとめてみました。ちなみに変更後にある赤点線は、「ストレージプールを作成すれば RAID を跨ってボリュームを作成できる!」と言うのを強調してものです。実際にはストレージプールの「どの部分」にボリュームがあるのかなどは全く表現できないのですが、個々の RAID 容量とその使用状況/空き状況は全く意識しなくても良く、ストレージプール全体の容量/使用状況だけ意識すれば良くなるわけです。

新構成は全体をひとつのストレージプールに設定しよう!

新構成へ移行する手順

Static volume の扱いが最大のポイント

この移行の最大のポイントは、すでに作成済みの Static volume の扱いです。Thick, Thin volume はストレージプール上に作成されていて相互の変換も可能なようです。しかしストレージプールのない Static volume は新たにストレージプール上のボリュームに移行できるのでしょうか?残念なことに同様の質問が QNAP のサポートに上がっていて、回答は No でした。

www.qnap.com

簡単な英語なので引用しておきます。

It is not possible to convert a static volume to a thin or thick volume (also called “flexible volumes”).

Static volumes are created directly from a RAID group. While thin or thick volumes are created inside a Storage Pool.

To be able to use the flexible volumes features, one would need to:

  1. Backup data from the static volume

  2. Remove the static volume

  3. Create new Storage Pool

  4. Create a thin or thick volume inside the new Storage Pool

  5. Copy the data back.

要は、バックアップを取った上で、static volume を削除して解放した RAID に新たなストレージプールを作成せよ、と言うことです。ただし私の場合、そのまま新しいストレージプールを作成してしまっては「二つのRAID にそれぞれ別のストレージプールができてしまう」ことになり、ストレージプールのスペースの柔軟性が全く享受できません。
私の場合は、「static volume をまず削除し、その後既存のストレージプールを拡張する」と言う作業が必要なようです。

ということで、次回は実際の作業のお話です。

QNAP NAS の ボリュームタイプ変更 (1) - 復習と現状の再確認

QNAP では 3種類(Static, Thick, Thin)のボリュームタイプがサポートされていて、NAS のセットアップの時点でどれかのタイプを利用するのか指定しなくてはなりません。これらに関する情報は決して少なくはないのですが、今ひとつ「しっかり納得できた」感が薄く、「とりあえず設定してみた」、と言うレベルで使っている人も多いのではないかと思います。そういう私自身も前の TS-431p の頃から「とりあえず設定してみた」まま使い続けていています。もちろん個人的な利用であればアクセス頻度もアクセス人数も極めて限定的なのでそうそう大きな差が出てることでは無いのでしょう。
たまたま今回 NAS のひとつのボリュームの容量が若干不安になっているので、HDD の容量アップもしくはボリュームタイプをもう少し腹落ちするまで理解した上で場合によっては思い切ってボリュームタイプの変更も考えてみようと思います。
なお、QNAP の資料をベースにしていますが、ここで登場する "Storage pool" や "Thin provisioning" という概念は QNAP 独自のものでは無く、Windows をはじめとする各種サーバーシステム、ストレージシステムでは現在標準的に提供されている機能のようです。もしもっと調べたいという QNAP ユーザーの方がいらっしゃいましたら、検索時に敢えて "QNAP" という単語を入れずに検索した方が沢山の情報に接することができます。

今回は一部用語をあえて日本語訳を使わず英文表記のまま使っている部分があります。これは QNAP に限りませんが、日本語訳に一貫性が無かったりするためです。
また、ここではディスク」という用語を HDD/SSD を含めた物理的なディスクドライブの総称として使うことにします。

基本的な用語の再確認 - 「ストレージプール」の理解が最重要!

一通り調べてから考え直してみると、二つの用語が明確になると理解が早まりそうですので最初にまとめておきます。以下の説明と合わせて、この後いくつか掲載している図を参照いただけるとわかりやすいかと思います。

「ボリューム」

  • いわゆる「ボリューム」として Finder / explorer で人間がファイルやディレクトリにアクセスする際に直接参照する対象ですね(Windows では「ドライブレター」で表す「ドライブ」のことですがここではボリュームという名称で統一します。)。システム上の設定としては、ボリューム単位で各種ファイルシステムを使ったフォーマットをした上でファイルを作成するのはパソコンも NAS も皆共通なことです。

  • ここでのポイントは、ドライブをどこに作成(配置)するかがポイントになります。

    • 一番シンプルな構成ではディスク一つを丸々一つのドライブに設定することですが、パソコンでは必要に応じて一つのディスクを論理的に分割して「データ用ボリューム(ドライブ)」など複数のボリューム(ドライブ)を作成することもできます。
    • しかし、通常複数のディスクをまたがったドライブを作成することはできません。そこでドライブをディスクではなく、次のストレージプールにボリュームを作成することでディスクやその容量を意識しなくても良くなります。

「ストレージプール」

  • これはパソコンには無い概念です。ひとつ以上複数のディスク・RAIDグループ(RAID構成をした論理的なドライブをここではRAIDグループと呼ぶことにします)をまとめたものを「一つのストレージプール」という一まとまりの記憶領域として設定することができます。それぞれのディスクや RAID グループの容量を超えた連続した記憶域として扱えるので、スペース効率が向上します

3種類のボリュームタイプ

いちばんわかりやすかった資料は QNAP のこちらの資料で、一覧表もあって網羅的に整理されていると思いますが、ポイントだけ先にまとめておきます。一覧表は最後に参考資料として転載させていただきました。

Static volume(静的ボリューム)

  • 一番シンプルで私たちがパソコンなどで接することが多いタイプで、ディスクもしくは RAID グループに直接作成します。それゆえ最大容量はディスクもしくは RAID グループの容量が上限となります。同時にディスク内に空きスペースがあったとしても他のディスクに作成されたドライブが使うことはできません。

  • 容量は最初に作成した時点の容量が確保されます。

  • 残りの二つで提供されるような高度な機能はありません。

  • ボリューム自体のパフォーマンスは他の二つより高速です。(逆に言えば他の二つは高機能にするオーバーヘッドがあると言うことですね。)

Thick volume(シックボリューム)

  • Thick と Thin はいずれも「事前にひとつ以上のディスクもしくは RAID グループに作成したストレージプール上に作成する」ので、物理的な単体ディスク容量を超えたスペースも利用可能です。Thich, Thin を合わせて "Flexible Volumes" と呼び、容量のメリット以外にも QNAP では smapshot, Qtier などの高機能なオプションが利用可能となります。

  • Thick と Thin は双方向で変換が可能。

  • Thick はあらかじめストレージプールに設定した容量のスペースを占有します。

  • パフォーマンスは QNAP の資料では Thick は Thin に比べて "slightly better" としています。

Thin volume(シンボリューム)

  • Thin の最大の特徴は実際に書き込まれたデータのサイズしか消費しないということです("thin provisioning")。

  • Thin ではボリュームサイズをストレージプールの容量を超えて設定することができます("over-allocation")。ただしこれは設定だけの話であって、10TB のプールに 20TB のデータを格納できるわけではなく、管理者は実際のスペース使用状況をモニターして適切な対応を取る必要があることには変わりません。これはおそらくパーソナルユースではほとんどメリットにはならないと思いますが、複数のユーザー(部門)があるような環境でストレージの管理者がいる場合には最大限のスペース柔軟性を得られるのでしょう。

www.qnap.com

わかりやすい図は

図で理解するのが一番良いと思うのですが、全体を網羅的に一枚の図で説明しているものは見当たりませんでしたが、基本となるストレージプールの位置付けがわかりやすいのは QNAP の YouTube で使われていたものです。 この図の最大のポイントは、

  • static volume は HDD/SSD(/RAID) 上に直接作成される

  • HDD/SSD(/RAID) 上にストレージプールを作成しその上に Thick/Thin volume を作成することで、Thick/Thin volume は直接 HDD/SSD(/RAID) を意識しなくて良い/制約から解放される

と言うことです。

QNAP の YouTube で用いられていた一番シンプルなチャート

他のサーバーシステムでは

他のサーバーシステムの資料を見ていると、ストレージプールの中にストレージプールを作成できたり、Thick にも種類があったりと、世の中色々な高機能化が進んでいるようです。これも SSD をはじめとするキャッシュやプロセッサ能力の向上に因るものなのでしょうね。個人ユースでは QNAP の機能でも使いきれない感じですが。

私の現状の構成

現在は static と Thick の併用

改めて自分の TS-453Be での設定状況を確認してみます。
最初にドライブと RAID 構成を確認すると、4台の 3TB の HDD を 2台ずつ二つの RAID 1 のグループに設定しています。

4台の ディスク で "RAID 1" 構成の「RAIDグループ」を二つ設定
RAIDグループ2 にはストレジプールを設定しボリュームはシックの設定

ボリュームタイプとしては、Static と Thick を使っています。「なぜ?」と聞かれてもあまり積極的な理由は多分無かったはずで、「自分が一番馴染んでいて一番高速」な static と、「QNAP が色々と高機能をアピールしているタイプもひとつ使っておくか」ぐらいで選んだと思います。

パフォーマンスは本当に違うの?

今までのキャッシュ化/10GbE に関するパフォーマンス測定は "Blackmagic Disk Speed Test" を使っていました。これは見た目はカッコイイのですが、メーターが示す瞬間の状態しか得られないので、スクリーンショットを撮るタイミングの情報しか残せませんでした。ただ実感としては static volume で測定したほうが 5% くらい高速だったと認識していて、今までのスクリーンショット大半が static で測定したものを載せていたと思います。
しかしもう少し数字でちゃんと測定/記録したいと考え、"AmorphousDiskMark" という Windows のツールに似た雰囲気のツールを導入して再測定してみました。
測定結果をざっくり言うと、「Sequential write で数% static が早いがその他はほぼ同等。体感上の差は無し。」と言う感じだと思います。volume の特性があってもキャッシュの効果がそれを打ち消しているのかもしれません。

static volume の結果

Thick volume の結果

static volume の結果 2

Thick volume の結果 2

念のためそれぞれの HDD のモデルも書いておきます。

モデル 容量
HDD 1 WD30EFRX-68EUZN0 2.73 TB (3 TB)
HDD 2 WD30EFRX-68EUZN0 2.73 TB (3 TB)
HDD 3 WD30EFAX-68JH4N0 2.73 TB (3 TB)
HDD 4 WD30EFRX-68EUZN0 2.73 TB (3 TB)

と言うことで、私の理解のポイントとしては以下の通りです。

  1. ストレージプールを設定するか否かがスペース効率と各種機能利用の分かれ道

  2. 最高速の static でもキャッシュ利用の元では体感するような差は無い

この認識のもと、次回 HDD 交換と新しい構成を考えたいと思います。


参考)ボリュームタイプの比較表

出典はこちら

Static Thick Thin
Summary Best overall read/write performance, but does not support most advanced features Good balance between performance and flexibility Enables you to allocate storage space more efficiently
Read/write speed Fastest for random writes Good Good
Flexibility Inflexible
A volume can only be expanded by adding extra drives to the NAS.
Flexible
A volume can easily be resized.
Very flexible
A volume can be resized. Also unused space can be reclaimed and added back into the parent storage pool.
Parent storage space RAID group Storage pool Storage pool
Volumes allowed in parent storage space One One or more One or more
Initial size Size of the parent RAID group User-specified Zero
Storage pool space is allocated on-demand, as data is written to the volume. This is called thin provisioning.
Maximum size Size of the parent RAID group Size of the parent storage pool Twenty times the amount of free space in the parent storage pool
The size of a thin volume can be greater than that of its parent storage pool. This is called over-allocation.
Effect of data deletion Space is freed in the volume Space is freed in the volume QTS can reclaim the space and add it back into the parent storage pool.
Method of adding storage space Add disks to the NAS
Replace existing disks with higher capacity disks
Allocate more space from the parent storage pool Allocate more space from the parent storage pool
Snapshot support (fast backup and recovery) No Yes Yes
Qtier (automatic data tiering) support No Yes Yes

「IIJ + 楽天モバイル」に移行完了した - Y!mobile から MNP 転出 - 久々の MNP で手間取る

サブで 2回線で利用している IIJ のさらに安いギガプランへの移行も自動的に完了したし、山歩きをしていて Y!mobile のメイン回線だけが圏外になることが他社より多いので、メイン回線も IIJ にしようというお話です。先月その準備編の作業を書いていますのでこちらも参考にしてください。
(念のための補足ですが、IIJ はドコモ回線と au 回線から選びます。)

blog0.kurikumachan.com

結論としては今回の移行の結果以下のように 3台4回線となりました。

  • iPhone 11 Pro [メイン(通話, LINE, 電子マネー..)] - IIJ <タイプD> ギガプラン4GB + 楽天モバイル eSIM 👈 今回のお話

  • Pixel 5 [ポケモン & 予備] - IIJ (タイプA)ギガプラン2GB

  • iPad Pro [RSS リーダー & twitter] - IIJ eSIMギガプラン8GB

  • 楽天 mini [とりあえず契約]楽天 eSIM を iPhone に DSDS 設定で引越し。

※5月現在でデータシェア機能がまだ提供されていないために今回の音声回線を 4GB にしていますが、6月にデータシェア機能が利用できるようになったら 2枚とも 2GB に変更予定です。


MNP 転出と転入

Y!mobile からの転出手続き - 驚くほどあっさりと

特にしつこい引き止めはありませんでした。 昔ドコモやソフトバンクから転出する際には「今解約するとこんなに損です!」としつこく引き止めのメッセージが繰り返し表示されたものですが、今回の Y!mobile では一才引き留めなし。拍子抜けするくらいでした。でもそのくらいドライな方がネガティブな印象も残らず、「また機会があったら使おう」って思えます。ただし私の転出操作が 21時を過ぎていたので MNP 予約番号は翌日に来ました。

あと Y!mobile で感心したのが IIJ への転入完了が Y!mobile 側に通知されてその後来たメール。最初何を言っているんだかわからなかったけれども、要は「契約無くなったから Y!mobile のメアド(@yahoo.ne.jp)はもう使えないけれど、紐付けしたあった yahoo メール(@yahoo.co.jp)で過去のメールを参照できるよ」と言うお話。正直言って Softbank/Y!mobile にはあまり好印象は持っていなかったのですが、ちょっといい感じのサービスだな、と思いました。私自身はキャリアメールを実質使っていないので恩恵はあまりありませんが、このサービスで救われる人もいるんじゃないかなと思いました。

f:id:KuriKumaChan:20210517211152p:plain
あなたは契約がなくなったけれども今までの送受信したメールは見せてあげるよ

IIJ での転入手続き- 既存ユーザーの SIM 追加メニューが見当たらない!

翌朝 MNP 番号も取れたので早速 IIJ 側で転入の手続きをしようと思ってふと考えたのですが、会員用の SIM 追加購入のメニューが見当たりません。あるのはギガプランの一般用購入ページのみ。もし純粋な新規購入ユーザー用として契約されてしまったら、来月からサービスが始まるデータシェア機能が使えません(同一契約内でのシェア機能)。ここは少し慎重になろうと考えチャットサポートで確認してみました。

f:id:KuriKumaChan:20210516224052p:plain
IIJ サポートとのチャット

結論としては同じ購入メニューでも会員ログインしてから操作すれば SIM 追加となる(ログインしなければ mio ID (ユーザー ID) の入力画面があとで出てくる)、とのこと。なるほど、余分なメニュー分けをしなくても良いという事のようです。が、同一契約での追加 SIM 購入をしようと考えているとちょっと悩む人は私以外にもいるような気がします。

IIJ SIM とプロファイル設定

中二日で SIM が届く

ちなみに IIJ の手続きは 05/13 (木) に実施して 05/15 (土) に「商品発送のお知らせ」が email で届き、05/16 (日) に SIM カードが届きました。土日にも関わらず早い!
で早速開通手続きに!

データ通信の開通に手間取る

みおぽんアプリから構成プロファイルがダウンロードできることを確認したら「あとはなんとかなるもんね!」と導入されていたソフトバンクのプロファイルを削除して念のために一旦電源 off/on した後に IIJ の構成プロファイルをみおぽんからダウンロード完了!IIJmio オンデマンド開通センターのフリーダイヤルに電話して準備完了!
で、一呼吸おいて通話が発着信できることを確認して安心して買い物に出かけたのですが、コンビニで PayPay で支払いをしようとしたらネットに接続できず PayPay の QR コードが表示できない!
「ああっ!家で Wifi off にしてデータ通信の開通を確認していなかった!」
と後悔... やむを得ず久々に現金を使うしか無いかーと思いましたがしかーし、楽天 eSIM も構成してあることを思い出し慌ててレジ前でモバイル通信を切り替え。多分 5秒くらいだったのがすっごい長く感じられましたが無事に楽天回線で PayPay が復活し無事支払い完了。楽天モバイルもちゃんと役に立った〜!
家に帰ってきて再確認すると、プロファイルをダウンロードしただけで「インストール」をしていない事に愕然。今度は丁寧にインストールまで完了して再度 wifi をオフにして IIJ のネット接続を確認。
が、構成プロファイルをインストールしても開通しない!
再度電源 off/on するとキャリア設定のアップデートが来ました。しかしこのキャリア設定アップデートって「どのキャリアに関するアップデートなのか?」が表示上全く分からない。もちろん事前に「設定→一般→情報」でキャリアのバージョンを控えておいてアップデート後にどのキャリアがアップデートされたのかをチェックすればわかるのだと思うけれども、そもそもアップデートの通知がいつ来るのかが予期できない。
結論を言えば電源 off/on が効いたのかキャリアアップデートが効いたのかわからないけれどもこの直後から IIJ のモバイル通信も無事開通。
んー、我ながら切れ味の悪い作業結果。残念だけれども無事開通したから良いということにします‥

みおぽんへの新回線の反映はデータ通信も開通しないと反映されないのかも?

IIJ にはデータ通信量の確認やクーポンの管理、無料の低速モードへの切り替えなどをできるみおぽんと言う IIJ ユーザー必須のアプリがあります。これは IIJ のユーザー id でログインさえすれば IIJ 回線でなくても使えるので事前に導入してあったのですが、IIJ サブ回線の 2回線は表示されても 3回線目の音声回線が開通した後もみおぽんには 3回線目が反映されませんでした。ネットで調べると「反映には時間がかかる」とありました。

iijmio-lab.com

しかし、上記のデータ通信も開通してしばらくしてみおぽんに 3回線目も表示されたので、もしかしたらデータ通信の開通がみおぽんへの新回線反映の前提だったのかもしれません。
(もちろん単に時間がかかっただけなのかもしれませんが)

ところで楽天モバイルの音声は?

こちらで紹介したように、たまに長電話を覚悟した通話(発信)もあります。そのためにセットアップした楽天回線と楽天の電話アプリ Link ですが、そう頻繁に利用するわけではありませんが、先月セットアップした直後はひどい音声品質でした。LINE 電話の方がよっぽどいい感じ。こりゃネットでも相当評判悪いなと思い調べると、「音声品質はそんなに悪くないですよ!」と言う言葉を選ばなければ提灯記事 (失礼!) のようなものがたくさんありました。その大半は「回線品質が良ければ大丈夫!」と言うものでしたが私の Wifi も回線品質も万全の環境で音声途切れ途切れだったので「これは使えないかも..」と半分諦め。
その時も何かのタイミングでキャリアアップデートが来たのです。楽天用かどうかは表示上ではわからないのですが、その時のメインの Y!mobile もしくはソフトバンクのキャリアアップデートが突然くると言うよりは普通に考えればやっぱり楽天のアップデートだったと思います。それが何かしらの影響があったのかどうかわかりませんが、まぁ使えなくはないレベルになったかな。Link アプリ使っていると品質に関するアンケートが出てきたりするので、品質改善の対応はしているようなので頑張ってもらいたいと思います。

QNAP と クラウドバックアップ (8) - 旧 Glacier の Vault が削除できない!- 最後は msp360 の CloudBerry Explorer !

前回までに QuDedup で思わぬ回り道をしてしまいましたが、前に進むことにします。今回はバックアップが期待するように実行されたバックアップジョブのスケジュール設定と、Glacier Deep Archive にバックアップできたので不要となった旧 Glacier の古いバックアップの vault (貯蔵庫) の削除です。特に Vault の削除は遅れれば遅れるだけコストがかかりますのでさっさと片付けてしまいたいところです。


1. バックアップジョブをスケジュールしてみる

以前の NAS (TS-431p)を使っていた頃は、クラウドバックアップは旧 Glacier にしていましたが、当時のフレッツ光が超絶遅いため初回バックアップに1週間かかったこともあり、気軽にバックアップし難いと考えていました(頻繁にバックアップすればさほどバックアップジョブに時間は取られないはずですが、フレッツ光遅し憎しでその気になれなかったと言うのが正直なところでしょうか)。
今となっては、ストレージコストもより安くなり回線は信頼の Nuro なので定期的なバックアップ(差分)に何の不安もありませんのでジョブにスケジュール設定してみます。

まずは HBS3 で設定

HBS3 でジョブのスケジュールを設定するのは簡単です。私は前回単発実行で作成したジョブを編集して自動実行のスケジュールを設定してみました。

ジョブ実行スケジュールを設定してみた。

スケジュールの実行結果

実は上の図のスケジュール設定は実行されませんでした。図のように必要な項目をポチポチっとやるだけなのですが、ここで「保存」ボタンを押し忘れていてスケジュール設定が保存されていませんでした。
で気を取り直して翌日に再設定してその後ちゃんと実行されていることを確認できました。

バケット内の HBS3 管理ファイルは毎回総入れ替え?

今回は差分バックアップがちゃんと行われるかどうかの確認しようと、事前にテスト用のディレクトリにテスト用ファイルを一つ作成しておきました。実行結果を確認するとちゃんとフィルサイズ 3MB のファイルがバックアップされていることが確認できました。ただ‥
3MB のファイル一つバックアップするのに転送データは 20倍以上の 68MB!

バックアップ元にあったデータ以外のファイルがバケット内にある

バケット内を確認すると自分のバックアップ元にはない "QNAP.....db" と "QNAP....info" と言うファイルが存在しています。どうやら HBS3 用の管理ファイルのようです。実際のバックアップファイル以外にもこれらのファイルも総入れ替えされているようでその容量が S3 Glacier の容量に含まれているのではないかと思います。

と言うことで、少量の更新データのバックアップに毎回同じオーバヘッドがかかってもつまらないので、当面今のスケジュールはそのまま週一回の差分バックアップで様子を見ようかと思います。

2. 旧 Glacier の不要となった Vault を削除してコストを削減する

新しい Glacier Deep Archive に(2つも)バックアップが取れたことを確認したので、旧 Glacier に残っているバックアップをさっさと削除してコスト削減したいところです。

AWS コンソールから削除できない!

AWS コンソール(ブラウザ操作)で Glacier に残っている Vault を確認し。一番上の Vault (クリッピングした CD などの iTunes ライブラリのバックアップ)を残して他の Vault を削除しようと思います。

毎月 $7 払っている Glacier の Vault

ところが Vault を選択して「ボールとの削除」ボタンを押してもエラーが発生します!

当然 AWS コンソール(ブラウザ)で削除できると考えていたのですが、ところがサイズが "--" になっているものは簡単に削除できたのですが、サイズに数字があるもの(つまり何かしらのバックアップデータが残っているもの)はコンソール上で削除しようとしてもエラーとなって削除できませんでした。

毎月コストが発生しているものだけが削除できないとは何とも言えない状況なのですが、調べてみると、

  • Vault の中にアーカイブと呼ばれるデータが残っていると Vault は削除できないので、先にアーカイブを削除しなければならない。

  • どのくらいアーカイブがあるのかは AWS コンソールから確認できる(山ほどの個数があった)。

  • アーカイブの削除は AWS コンソール(ブラウザ操作)から行うことはできず、CLI (コマンド・ライン・インターフェース)か API で実行する。

と言う衝撃的な事実が発覚しました。もちろんアマゾンが隠していたわけではなく、私がデータを放り込むことしか考えずに使っていただけなのですが、ショックでした😭

dev.classmethod.jp

AWS CLI でアーカイブを削除する

このアマゾンの説明を参考にアーカイブの削除をしてみました。 docs.aws.amazon.com

一言で CLI を説明すると、Mac のターミナル(Windows のコマンドプロンプト)から "ls" (dir) といったコマンドを入力するのと同じように "aws s3 ..." か "aws glacier ..." とコマンドを入力して結果を得るものです。"aws" コマンドを使えるようにするには AWS CLI を導入する必要があります。

AWS CLI のセットアップ

AWS CLI は昔々 Windows PC で軽く使っただけで、今の Macbook Pro では AWS CLI を使ったことがなかったので新規導入しました。導入ガイドは本家アマゾンのもの以外も色々あるのでネットで検索してみてください。人にパッケージマネジャーを使っていればそれにあった導入手順も紹介されています。
私は homebrew で導入してみましたが、CLI 導入の過程で Python 3.9 が無いからビルドできない、なんてエラーが出たりして少し手間取ってしまいました。もしどうしてもこういった導入が敷居が高すぎる、ということであれば、この後紹介する msp360 CloudBerry Explorer を試してみるのも手かと思います。

% aws --version
aws-cli/2.2.0 Python/3.9.4 Darwin/20.3.0 source/x86_64 prompt/off

CLI を使って手作業で削除できたけれども

さて、CLI 環境が導入できてしまえばコマンド入力はすぐできます。が、単純に「即削除」はできず手順を踏んでしかもある程度時間をかけなければならないことがわかりました。(時間さえかければ作業は単純)
手続きは以下の通りです。(「パラメーター」は "aws glacier" に続くもの)

  項目 手段 CLI のパラメータ 入力項目 出力項目
Vault の確認 コンソール - - Vault名
インベントリー作成ジョブの開始 CLI initiate-job Vault名, job-parameters '{"Type": "inventory-retrieval"}' jobId
ジョブステータスの確認※1 CLI describe-job Vault名, jobid StatusCode
インベントリーの取得※2 CLI get-job-output Vault名, jobid, 結果用ファイル名 (結果は指定のファイルへ)
アーカイブの削除 CLI delete-archive Vault名, jobid, archive-id
Vaultの削除 コンソール

※上記の入力項目以外に "account id" が必要です。
※1 これはジョブが完了するまで繰り返し実行し、StatusCode が "Succeeded" になることを確認します。完了までに数時間(6時間くらい?)かかりました。
※2 入力で指定したファイル名に、インベントリー情報がダウンロードされます。その中にある山盛りの "archive-id" 一つ一つが削除すべきアーカイブです!

この辺りは下記二つの記事を参考にさせていただきました。

Amazon GlacierのVaultを削除する手順 - muo-notes

Amazon Glacierの一通りの流れ - Qiita

インベントリーの取得で、残存しているアーカイブの情報が指定したファイルにダウンロードされるので、その中から "archive-id" を探して "aws glacier delete-archive ...--archive-id archiveid " と入力すればアーカイブが一つだけ削除できます
しかーし!不要な vault には消さなければならないアーカイブが 278,152個もある!

AWS コンソールで Vault に残っているアーカイブの数は確認できる。

と言うことで、アーカイブを一つ一つ削除するコマンドの手動投入は諦めざるを得なくなりました。

スクリプトにしてバッチ処理もできたけれども

と言うことでバッチ処理にしてみました。 インベントリーの出力ファイルは json だったので、そこから archive-id だけを278,152個取り出してコマンドをシェルスクリプトにして実行しました。
が、コマンド一つがおおよそ 1秒かかります。ですので、約 28万秒 = 3日以上かかることが一晩放置してから分かりました(何という計画性のなさ‥)。そのまま放置しようかとも思ったのですが、Mac で初めて karnel_task が暴走してバッテリー残が 5%と瀕死の状況(純正 AC アダプターではなくディスプレィから USB PD で普段利用しているのですが、ワットが足りない)。

結局

と言うことで、CLI でアーカイブを削除できることは検証できたのですが、とても全量を削除するのはバッチ処理でも追いつかないので別の方法を試してみることにしました。

msp360 CloudBerry Explorer を試してみる

これからご紹介する方法は Mac 版もあるようですが、私がなぜか Windows 版しかないと誤解して Windows 版で試してみましたが、ちゃんとアーカイブの削除まで行えることを確認しました。

これはたまたまネットで見つけたのですが、各種バックアップソリューションを提供している MSP360 (以前は CloudBerry Lab) と言う会社とその CloudBerry Explorer と言うソフトが活躍してくれました。 www.msp360.com

もちろん有料ソフトなのですが、15日の無料トライアルがあったので何とか2,3日で決着をつけようと頑張りました(ちなみに買うとしたら $59.99)。私のように旧 Glacier と決別しようとして最後のあがきで操作しなければならない人は(ビジネスの邪魔をするわけではありませんが)free trial で問題ないと思いますが、旧 Glacier と今後もお付き合いする方は購入を検討した方が楽になれるかもしれません。具体的な操作は下記リンク先を参照いただければ雰囲気わかると思います。

kb.msp360.com

基本 Windows のエクスプローラーで Glacier の Vault やアーカイブをドリルダウンできるイメージです。なの直感的に分かりやすいと言えば分かりやすいです。少なくとも CLI パッケージの導入はしなくて良く、単なるソフトの導入を行うだけですし。 ただし、CLI でやるにしても CloudBerry Explorer で操作するにしてもサーバー側処理は変わらないので、例えば「インベントリー作成ジョブの開始」つまり CLI では initiate-job に相当する "get inventry" メニューはあって、その結果が反映されるにはやはり何時間もかかります。
あと私が戸惑ったのは、278,152個のアーカイブリストの全体を選択して delete する操作で若干不安になりました。リストの先頭をクリックしてリストの最後に移動してリストの最後をクリックして全体を選択、と言う操作自体が「本当に全てを選択できているの?」と言うのが確認できず不安でした。それが ok だったと確認できたのは、CLI のバッチ処理で 10万個くらいしか削除できていなかったはずなのにコンソールで確認したらアーカイブの数が "__" となっていて vault も削除できたので CloudBerry Explorer が正しく機能してくれたと確認できました。

ようやくアーカイブを削除することができた

そして Vault もコンソールから削除できた!


と言うことで、3日間 CloudBerry Explorer を使わせてもらって旧 Glacier を全て削除することができました。やれやれ。

QNAP と クラウドバックアップ (7) - ".qdff" と ".qdv" の謎は QuDedup → バックアップやり直し

前回までに 2回の Glacier Deep Archive へのバックアップを行いました。バックアップのテストでは AWS コンソールから S3 バケット内部にアップロードされたディレクトリやファイル名がそのまま確認できていたのに、本番バックアップではディレクトリ構造がバックアップ元と異なった(".qdff" ディレクトリなんてのができていた)り、ファイル名自体がオリジナルのファイル名と異なり拡張子が皆 ".qdv" になっていたりと気分的に落ち着かない状態となっていました。単にジョブの実行結果を見ていただけなら何も不安に思わなかったと思うのですが、旧 Glacier と違って S3 の一員になってバケットの中身を AWS コンソールから確認できるようになって、実態を目の当たりにしてしまい衝撃を受けたといっても言い過ぎではありませんでした。

調べてみると ".qdff" ディレクトリの正体は

ネットを調べてみると、どうやら HBS3 の新機能?の "QuDedup" なるファイル圧縮機能を利用した時に作られるディレクトリ/ファイルだったようです。

qdff は QuDedup テクノロジーを適用した結果

QuDedup とは

私の理解では、一言で言えば QNAP NAS データを他の NAS やクラウドにバックアップする際にデータ量を減らすことによりスペースも処理時間も節約できるという機能のようです。
「バックアップデータの重複を排除」という謳い文句がファイル単位の重複なのかどうか不明なので何とも言えませんが、それだけでは今回の私のデジカメファイルのような基本的には同じファイルが存在しないデータ群には余り向いていないような気がします。別の脈絡で(上図にありますが)「QDFFファイル圧縮で‥」という表現からもしかしたら重複排除以外に強力なデータ圧縮アルゴリズムも備えているのかもしれませんが、素人レベルに「なるほど〜!」というほどの納得感のある説明は見当たりませんでした。
(QNAP さん、私が見落としていたらけでしたらゴメンなさい。)

www.qnap.com

効果は?(紹介記事)

QNAP 製品を取り扱っているフォースメディアさんの記事にあったテスト事例では「3割近く」(ほぼ2割ではないか?というツッコミはありますが)効果があったとされていました。

オリジナルデータは7GBほどでしたが、重複排除(Qudedup)で3割近く削減されました。
7GB → 5.62GB

www.forcemedia.co.jp

効果は?(私の場合)

私の場合の容量をバックアップ元と S3 のバケット容量を比べてみると、

  • バックアップ元(NAS 上の外付け HDD): 1.05TB (Qfile の表示)

  • バックアップ先 (S3 Glacier Deep Archive):777.6 GiB (AWS CLI での表示)

単位の桁が違いますし、GB/TB と GiB/TiB では同じバイト数に対する値も異なり同じ値であれば Gib/TiB の方がやや大容量であることを示すようですが、そんなに劇的に圧縮されているようではありません。(GiB/TiB に関してはこちらの記事を参考にさせていただきました。)

www.guri2o1667.work

容量面での効果はともかく、仕事上バックアップを行うのであれば、Qudedup をもっと時間をかけて勉強したりテストするのですが、趣味で(当然無給で)時間をかけて頑張るほど暇ではないのと、今のところさほど大きなバックアップ保存コストにもなっていないこと、そして何よりアップロードした S3 バケットの中身がファイル単位で確認できるか否かというのは精神安定上違いが大きいので、私は Qudedup はオフで使いたいと思います。

QuDedup Extract Tool というのもある

完全に私の使い方ではないのですが、ローカルに qdff ファイル/ディレクトリをダウンロードした後にそれを解凍するソフトも提供されているようです。仕事で使うのだったら何か用途があるかも。

https://www.qnap.com/ja-jp/how-to/faq/article/qudedup-extract-tool-%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6-qdff-%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB%E3%82%92%E3%82%A8%E3%82%AF%E3%82%B9%E3%83%88%E3%83%A9%E3%82%AF%E3%83%88%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95www.qnap.com

なぜ本番バックアップだけ QuDedup が機能したのか?

これは完全に私のオペレーションミスでした。 HSB3 に残っているジョブの構成を確認すると、後から変更できないようにグレーアウトされていますが QuDeDup にはチェックが入っていました。ジョブ設定時に一通りの設定項目は確認していて、テストバックアップではこのチェックを外していたのですが、肝心の本番の時に外し忘れてしまったようです。

後から変更できないようにグレーアウトされているが QuDeDup にはチェックが入っていた。

再度 "QuDedup" をオフにしてバックアップ - 今すぐやるか 180日待つか?

私にはさほどの価値はなさそうな QuDedup オプションでバックアップしてしまったので、早速削除してバックアップを取り直そう!と思ったのですが、 Glacier Deep Archive には「最小ストレージ期間料金」という制約があることを思い出しました。

Glacier Deep Archive の最小利用期間は 180日
要は仮にすぐに削除したとしたも、最低 180日分の保存コストは発生する、ということです。もし QuDeDup オプション無しのバックアップも取った場合、QuDeDup オプション付きのバックアップを削除しようがそのまま残そうが、180日(近く)はダブルでコストが発生してしまうのです。私の取りうる対応は大きく二つです。
(1) 180日待ってQuDeDup オプション付きのバックアップを削除するとともにオプション無しのバックアップを新たに取る。(重複コストが無い)
(2) さっさと QuDeDup オプション無しバックアップをとって 180日後にオプション付きのバックアップを削除する。(重複コストを受容)

重複コストはどのくらいかと言うと、前回ご紹介したように $0.05/日 (正確にはバックアップ以外の用途で使っている $0.01 も含まれているので $0.04 ですが)で、180日で $9。

1日あたりの S3 保存コストは $0.05/日 = ¥5.5/日
180日と言えば 3ヶ月なのでそろそろ老化が目に見えてきているので、これまでの作業が頭にあるうちに対応しておいた方が良いだろうと考えることにしました。

と言うことで、再度ジョブを設定して実行!

実行結果( "QuDedup" オン/オフの比較も)

当然ジョブは成功です!

HBS ジョブ実行結果

HNS3 に残っている二つのジョブのレポートから数字を拾ってみました。

  項目 QuDeDup 付き QuDeDup 無し
処理時間 11:24:16 11:14:21
合計ファイル数 190132 190132
合計サイズ 832.08GB 832.08GB
転送サイズ 777.58GB 832.14GB
合計転送速度 19.39MB/s 21.06MB/s
データ縮小率 1.07 1

確かに転送サイズは少しですが QuDeDup の指定をした方が少なくなっていることは確認できましたが、私のデータセットの場合はさほどの効果ではないと言うのが素直な感想です。

AWS コンソールからの確認

当然ですが、ちゃんとディレクトリ構造やその下のファイル名まで確認できました。

一つ一つのファイル名まで確認できて一安心 ♪

本来やるべきことにチャレンジ!

さて、次回は本来やるべき二つのことに前進しようと思います!
- 旧 Glacier バックアップデータの削除
- バックアップジョブのスケジュール実行