雑記」カテゴリーアーカイブ

micro:bitのプログラミングがある場所では動作しなくなる?

ちょっとmicro:bitのプログラミングに関していろいろとやってみる機会があったので使っていたのですが、その中で気が付いたこと。ほかのサイトでも書かれていますが、こちらでもちょっと触れてみたいと思います。この件は一部の環境の人にはとんでもなく刺さる問題になっています。

 

micro:bitの主要なプログラミングツール

皆さんが使うのは大体このあたり、ということで示しておきます。

Microsoft MakeCode for micro:bit (https://makecode.microbit.org/)

インターネット環境とブラウザでプログラミングできる環境として有名です。使おうと思えばAndroidでもiOS系でも使用可能です。その場合は作成したhexファイルをどうやって転送するのか、を考える必要があります。ちなみに2020年6月にバージョンアップしてv3になっています。そのため、いくつかのブロック(Scratch)が追加されていたり、対応言語が増えているなどかなりの恩恵があります。対応している言語は「Scratch」「JavaScript」「Python」です。Pythonの場合はパッケージ指定がいらないので作成にはもってこいかもしれません。しかしながら、このバージョンアップがある悲劇をもたらしています。それは後ほど。

Micro:bit offline App – MakeCode (https://makecode.microbit.org/offline-app)

こちらはインターネット環境およびブラウザが利用できない場合に利用可能な方法です。Windows10とMacOS対応です。インストールが必要なのが欠点ですが、v3ベースの開発環境が使えるので実験する量が多い人はこちらをインストールしてしまうのもありかもしれません。Windows10の場合はストアアプリから同様のものを手に入れることが可能です。言語はオンラインv3版と同様。

Python Editor for micro:bit (https://python.microbit.org/)

Pythonを使う、と決めているならこちらを使ってみるのもよいかもしれません。こちらの場合はMicroPythonで動かすことを前提にプログラムを組むのでMakeCode版とは微妙に作り方が違うことに注意が必要です。ファイル転送に関してもpyファイルおよびデータファイルを指定すればhexファイルにくっつけた形で転送可能です。プログラムのサイズに限界があるmicro:bitにとってはデータファイルが使えるのでうまく組めばMakeCode版に比べて規模を大きくすることが可能です。

Muエディタ (https://codewith.mu/)

Pythonのエディタです。こちらに付属するmicro:bitの転送ツールを使うとpyファイルおよびデータファイルを転送することができます。こちらもMicroPythonベースですので気を付けましょう。

Androidアプリ or iOSアプリ

スマートフォンしか手元にない場合はこれらのアプリを使って作成&転送ができます。転送方法はBluetoothで、micro:bit側を特殊な待機状態にしてペアリングし、プログラムデータを転送します。失敗するとPCからhexファイルの送り直しになるという救援が必要ですが、ちょっとした実験やPCが台数分確保しづらい学校環境などではこれをインストールしてもらって実行する、というのもありかもしれません。

 

MakeCodeのブラウザでIEのサポートが外れたため大変なことに

v3へとバージョンアップしたときにInternetExplorerのサポートが打ち切られました。これ自身はまあかなり古いブラウザので仕方がないのかもしれませんが、ちょっと問題になっているらしいのが「学校で使用できるブラウザとしてInternetExplorerが強制されていることが多く、サポートがなくなって使えなくなってしまう」というものです。学校の環境では自由にインターネットをさせるとまずい場面があるため、それの制限が必要なのですが、IEを使用させてEdgeを使用不可にしている、というパターンが多いようです。このため、プログラミング演習がちょっと厄介なことになっています。

 

回避策は…

学校環境を前提にしていくつかありますが、どれも微妙です。

・MakeCodeのv2版を使う

一応過去版が使用可能です。過去版はv2版でURLに直接「/v2/」を入れる必要がある、つまりhttps://makecode.microbit.org/v2/への直接リンクが必要で、入力作業がかなり面倒だったりします。まあ、ショートカットを使ってごまかすことはできそうですが…ほかにもv3版で追加されたブロックやPythonが使えないこと。さらに根本の問題としてMakeCodeのv2版の期限が2022年まで、ということであと2年後にはIEの制限が解けない限りは同じ問題が起こることになることです。管理ソフトを作っている人たち、この問題は早めに解決しておかないとそもそもIEで正常にアクセスができないサイトがだいぶできていて問題ですよ、と言いたい。G Suite関係もサポート外になりそうですし。

・オフライン版のインストール

PCへのインストールが可能ならばこれで避けることは可能です。しかもv3版になりますのある程度新しい部分まで使うことができます。問題点は「インストールが可能ならば」のポイントで、環境を変えてしまう等の理由で認められない場合には使うことができません。無念…。

・Android版やiOS版のアプリを導入したタブレットで行う

特にコード入力ではなくScratchによるプログラミングを行うことが前提となる小学生レベルならばこのほうが逆に簡単かもしれません。問題は必要となる台数を確保できるか、というところ。まあ、このコロナ禍の影響でコンピュータなどの導入計画が早まっていますのでアプリが導入できるならこちらもありかもしれません。相変わらず導入制限があるとうまくいきませんが。

ちなみに、実機転送を行わずにシミュレータのみで動作を見る場合はタブレットからMakeCodeにアクセスさせる、という手段をとることができます。タブレットの場合はブラウザがChromeかSafariになるはずですのでMakeCodeの制限は越えられると思います。

・ポータブル版のブラウザを授業毎に導入して終了後無効にする

ちなみにたいていの学校のPCはちゃんと環境復元ソフトがある(もしくは学習環境管理ソフト内に同等の機能があるはず)なので、先に起動させておいてブラウザだけ入れておく、終われば即シャットダウン、という形でごまかすことが可能な環境はあると思います。もちろん、これはPC管理のポリシー違反になる可能性が高いのでかなり危ない回避方法だといえるかもしれません。私も考えはしましたが多分使わないでしょうね…。

 

今年の回避策はv2版になるのかな…

まあ、たいていの学校は演習でmicro:bitを使う場合はこれになるのでしょうね。よほど込み入った演習をやる予定か、プログラミング演習でコードを用いる演習をしたくて、かつそのコードにPythonを選ぶ、という場合でもない限りは、ですが。一応JavaScriptもあるので、Pythonをやらなければならない理由がないのであればそちらで頑張ってみてください、ということになるでしょうかね。

 

MEGA BIG1等が出るまで対象回の当選確率表を更新していく

ちょっと楽しくなってきたのでMEGA BIGの1等当選確率の推移(当選者が出ない確率など)をどんどん更新していってみたいと思います。今回から各回における1等当選確率も同時に表示するようにしています。まあ、グラフにするようなものでもないので表の形で出したいと思います。

回数 口数 不成立試合数 1等が出ない確率 (1等が出る確率)
1154 1,817,907 0 89.16% 10.84%
1158 964,243 0 94.25% 5.75%
1164 681,109 0 95.94% 4.06%
1165 738,106 0 95.60% 4.40%
1166 766,803 0 95.43% 4.57%
1167 979,506 0 94.16% 5.84%
1168 929,445 0 94.46% 5.54%
1169 1,288,401 0 92.32% 7.68%
1170 1,301,594 0 92.24% 7.76%
1172 1,277,528 0 92.39% 7.61%
1174 1,364,647 1 67.46% 32.54%
1175 943,168 0 94.38% 5.62%
1176 1,228,281 0 92.68% 7.32%
1178 1,514,454 0 90.97% 9.03%
1180 1,460,009 1 65.19% 34.81%
1181 962,565 0 94.26% 5.74%
1182 1,149,320 0 93.15% 6.85%
1183 2,402,965 0 85.68% 14.32%
1185 2,531,145 0 84.91% 15.09%
1187 2,508,561 0 85.05% 14.95%

ここ何回かは少しだけ口数が上がっていますが、それでも当選確率が20%を下回っているのでかなり厳しいですね。ちなみにこれで前回(1187回)のMEGA BIGの口数とBIGの口数は大体同じです。

なお、次の回に1等が出ない確率に今までの出ない確率などは一切関係しません。これはくじの結果はそれぞれの回での独立試行と考えられるためです。なので、口数の変化はそこまでないでしょうから、次回も1等が出る確率は良くても20%位になるのでは?と推察されます。ちなみに確率論で間違えないで欲しいことは当選者が出ない状態が積み重なったからと言って次回当選者が出やすくなるわけではない、ということ。まあ、キャリーオーバーと確率を考えると次回当選者が出ればほぼ確実に12億円だということくらいですし、完全に確率論だけでこの手の当選状態が支配できるようなものでない可能性もごく微少にはある可能性もない訳ではない…のか?

参考までにMEGA BIGが今までに1回も1等当選者が出ない確率は計算すると約9.785%となります。高いのか、低いのか…。

 

MEGA BIGに1等が全く出ていないのは不自然なのか?その確率は?

ということで、またもや確率ネタです。今回もおそらく数Aレベルで分かる話になっています。単純にこの記事を書いている8月末現在でMEGA BIGは一回も1等が出ていません。一応当たれば12億円となるだけのキャリーオーバーがたまっていますが…。この記事を書いている今週末には台風が来る予想になっていると言うことで、もしかすると試合が中止になって確率が上がり、当選者が出るかもしれませんので書いています。それが自分だとうれしいのですが…。

まあ、それはさておき。これを確率的に追いかけてみるとMEGA BIGの確率がBIGなどに比べるとかなりやばいということが分かる、という話です。抽選方法が出た時点から「最低でもキャリーオーバーがたまって12億円の払い戻しができるようになるまで行かないと割に合わない」とは言われていました。そして人によっては機械のランダムに何かあるのでは?と疑いたくなる人もいるかもしれませんが、これを数学的に解いていきます。

 

結論としては「十分にあり得る状態」であるといえそう

計算結果は8月末の状態で約16.5%の確率で「ここまで1等が一つも出ない」と出ています。16.5%といえば1/8より大きいですのでそれなりにあり、というところでしょうか。個人的にはもっと低い状態、だいたい10%を切るくらいのところで、「珍しいくらい」と書きたかったのですが…。ちなみに厳密にしたいのであれば検定を行うべきなのでしょうがそれは省略しています。この時点で確率として極端に低いわけではないですので。

 

くじの確率の前提知識

一般的な「偏りのない場合」で単純に当たりか外れかを考えるだけのくじについて考えます。くじのパターンがn通りで当たりがh通りとする場合、

1本引いてそれが当たりの確率:h/n

1本引いてそれが外れの確率:1-(h/n) [余事象の確率]

くじを確認したら戻す(復元抽出)とき、m本引いてすべて外れの確率:(1-(h/n))^m [反復試行の確率]

これと「独立な試行において2つの事象が同時に起こる確率はそれぞれの確率の積になる」を使うと今回目的の確率を出すことができます。

 

問題はMEGA BIGの確率が小さすぎる点

通常のMEGA BIGにおいて、くじのパターンは4^12通りとなるので、計算すると16777216通りとなります。BIGの3^14通り=4782969通りに対して約3.5倍という状態となり、かなり厳しい確率になっています。確率の減少度合いと1等金額の上昇が微妙に釣り合っていないんですよね…。なので「キャリーオーバーがたまるまで割に合わない」となるわけですが。これに追加してBIGより購入口数が少ないことも響いて、こんな感じの表ができあがります。

 

確率計算をしてみると…

こんな感じの表になります。

回数 総口数 欠試合数 パターン数 1等なし確率
1154 1817907 0 16777216 89.73%
1158 964243 0 16777216 94.41%
1164 681109 0 16777216 96.02%
1165 738106 0 16777216 95.70%
1166 766803 0 16777216 95.53%
1167 979506 0 16777216 94.33%
1168 929445 0 16777216 94.61%
1169 1288401 0 16777216 92.61%
1170 1301594 0 16777216 92.54%
1172 1277528 0 16777216 92.67%
1174 1364647 1 4194304 72.23%
1175 943168 0 16777216 94.53%
1176 1228281 0 16777216 92.94%
1178 1514454 0 16777216 91.37%
1180 1460009 1 4194304 70.60%
1181 962565 0 16777216 94.42%
1182 1149320 0 16777216 93.38%
1183 2402965 0 16777216 86.66%
連続1等不当選確率 16.49%

口数については公式発表のページより持ってきています。計算はExcel任せですが、一応関数電卓でも計算させてありますので数字に間違いはないと思います。あと、一部の回で試合が中心になった影響でくじのパターン数が減少したものがあるのでそれも加味しています。(詳しくは前のページを参照)

そうだとしても、1等が出ない確率が各回単体で見るとでかなり高いのが分かります。総口数が(パターン数に対して)少ないため、BIGのように毎回出るか?出ないか?という感じにならないわけですね。試合が中止になればちょっとましになりますが、それでも70%以上の確率で1等はでない、という状態になっているようです。これだとくじのパターンを決めるアルゴリズムは公平だとしても、当選が出るのはそれなりに珍しい、という結論に至るかと思います。

まあ、口数を公式発表から持ってこなくてもここまでのキャリーオーバーの金額およびそれぞれの分配率から大体の確率は計算可能です。試合の中止による確率上昇は加味できませんが。

 

早く1等を見てみたい…

さすがにここまで1等当選が出ないのは予定外なのかもしれません。CMもそれなりに打ち始めているようですし、その影響で最新回は今までの中で総口数が最も多くなっているため、1等が出ない確率は多少下がっています。これくらいの口数があり、かつ1試合中止になれば当たりも見込めるのではないでしょうか。という希望的な観測を書いて終わりにしたいと思います。

 

BIGの一等当選確率はどれくらい試合中止になると二等レベルになるのか?を計算してみよう

ということで、ちょっとした数学ネタになります。試合が中止になりやすい今だからこそ少し考えてみたい話題です。

 

前知識:BIGやMEGA BIGの一等の確率について

確率を考えるときにはBIGやMEGA BIGがどのようなくじか確認する必要があります。確認すると

  • BIG:特定の14試合について勝ち・引き分け・負けをコンピュータがランダムに選ぶ
  • MEGA BIG:特定の12試合について総得点を4パターンで表し、それをコンピュータがランダムに選ぶ

というものです。ということで、それぞれ一等の確率を考えると、すべて当たったときが一等なので

  • BIG:1/(314)=1/4,782,969
  • MEGA BIG:1/(412)=1/16,777,216

となります。この確率の計算はそれぞれ3通り(BIG)or4通り(MEGA BIG)の試合結果がそれぞれあり、その試合が14試合(BIG)or12試合(MEGA BIG)なので、積の法則からこれが成り立ちます。試合の結果はそれぞれ独立なのでこれでOKですね。ちなみにこれを見てもらうとわかるとおり、確率的にはMEGA BIGの一等はBIGの一等の1/3以下の確率になっています。なので当選金額としては大分不利ではないでしょうか。

 

では二等の確率はどう計算される?

次は二等です。二等は「いずれか一試合の結果が外れていた場合」となります。今回の確率の計算で注意が必要なのが「いずれか」の言葉。どの試合の結果が外れていてもよいので、考えられるパターン数は「外れの試合の結果のパターン数×全試合数」となります。つまり、

  • BIG:パターン数は(3-1)×14=28通り。よって確率は28/314となり、約170,820分の1になる
  • MEGA BIG:パターン数は(4-1)×12=36通り。よって確率は36/412となり、約466,034分の1になる

という結果になります。LOTO6やLOTO7に比べると一等と二等の確率にだいぶ開きがあることがわかるでしょうか。

 

試合が中止になった場合はどうなる?

試合が中止になった場合は「その試合はどのパターンでも当たりとする」となります。ちょっと言い換えると「ある特定の試合だけ外れていてもよい」となります。注意が必要なのが「特定の試合だけ」というもの。いずれか、ではないので1試合の場合一等のパターン数は「1試合のパターン数」しか増えません。複数の試合になると積の法則から「(一試合のパターン数)(中止になった試合数)」が一等のパターン数となります。例えば1試合ならば

  • BIG:1試合のパターン数は3なので、確率は3/314=1/313=1/1,594,323となる。
  • MEGA BIG:1試合のパターン数は4なので、確率は4/412=1/411=1/4,194,304となる。

ということで、確かに確率は上昇していますが、二等レベルまでは増えていません。もし二等レベルまで来るとしたらそれは二等のパターン数と見比べると

  • BIG:3試合の場合のパターン数が33=27通りなので、3試合中止くらいで通常時の二等くらいの確率
  • MEGA BIG:2試合の場合のパターン数が42=16、3試合の場合のパターン数が43=64なので、2試合中止ではまだ足りないが3試合中止まで行けば十分

となります。ちなみに確率を比べてみると通常のBIG1等の確率と1試合中止でのMEGA BIG1等の確率が(大雑把ですが)やっと同じくらいになります。このことから1試合中止が確定している場合で十分にキャリーオーバーがあり、BIGのキャリーオーバーが少ないならMEGA BIGを買う、という選択肢もなくはない、という結論に至ります。あまり勧められませんが。

 

結局一等を当てやすいのは試合中止が決まっているときの100円BIGという話に

○億円レベルの当たりが期待でき、という条件だとこうなるのではないか、と思います。口数が稼げるので確率も(多少ですが)増えますので。まあ、コロナウイルスの影響で全試合中止など4月のような状態になればそうも行っていられなくなるのでしょうが…。ちょっとした考察でした。

 

真面目に48TBファイルサーバを構築してみる(5) サーバ構築編

これまでにPCの組上げやパーツの特性のチェックなどが終わりましたのでやっとサーバの構築に入ることができます。なお、この構築でも本来の予定と異なったことをやっている場面がありますので、そちらも紹介していきたいと思います。

 

サーバのOSは…Ubuntu?

いままでNASサーバは安定性重視でCentOSを使ってきました。サポート期間も長く、今までRedHat系をよく使っていたためなれているという部分もあったためです。そのため、はじめはCentOS8をインストールして設定、と思っていたのですが、インストール時にいくつか問題点が発生していろいろとOSを試しているうちになぜかUbuntu 20.04 LTSになりました。先に原因を書いておくと、今回の場合は

  • CentOS8をインストールするときになぜかNICが正常に応答せず、通信ができなかった
  • インストールパーティションの設定でソフトウェアRAID(mdadm)を設定するときの使い勝手がUbuntuに比べて悪い。RAID1による保護をかけるための設定で、パーティションごとにRAID1を設定されるなど非効率な場面を作ってしまった。
  • ZFSをCentOS系で使うときの手順がかなり複雑である(と聞いている)。dkmsなどの機構が必要になる可能性が高いらしいので安定性が下がるかも。

というものでした。一番はじめのやつが致命傷でした…。

 

FakeRAID(Intel RST)はLinux系OSのインストール時に使用できないと思った方がよい

これもサーバOSを入れるまでに時間がかかった原因です。今回メインHDDはRAID1を組んで障害に耐える構成にする予定でしたので、これをLinux側でやると故障時の対応がややっこしそうだったため、Intel RST側でRAID1を組んで…と思っていたのですが…。RST側でRAIDを組むとLinuxのインストーラがRAIDのHDDを発見できない、という悲劇が発生します。解決するための方法はあるにはあるようなのですが、「インストーラ起動時のオプション設定でdmraidを有効に…」などと書いてあり、やってみても全くうまくいかず、CSMの影響か、とも思いM/BでCSMを設定すると今度はUEFIが見えなくなるという悲劇を数回行い、そのたびにCMOSリセットをせざるを得なくなる羽目に。

改めて書いておきますが、FakeRAIDはLinuxでは相性がかなり悪いので普通にmdadm経由でRAIDを設定するのが正しいようです。そのため、HDDはAHCIで接続させ、Linux側でSoftwareRAIDを設定しましょう。

 

同じ容量のHDDを指定すればインストーラ側がちゃんとRAIDの領域を作ってくれるらしい

心配になっていたのがこの部分。データ領域はRAID1による保護を行うのですが、領域を切り出したときに「それぞれのHDDに同じ容量のパーティションを作成してRAIDを設定する」が果たして守られるのか?ということだったのですが、これは問題はないようです。しかも今回はブート領域にRAIDを設定することができない関係でHDDまるごとRAID1にはできないことを逆用してswap領域をRAID0、データ領域をRAID1で設定するというちょっとだけ速度を向上させる設定にしてみました。swap領域は一時領域なので故障を気にせず速度寄りに、もしHDDが故障した場合はもう片方にバックアップ用のブート領域およびRAID1の保護領域があるので、ブート領域のコピーおよびRAID1の回復作業を行うことで復旧が可能になっています。

 

swap領域があるならswapファイルは無効化してしまおう

Ubuntuの場合はswapファイルが自動的に作成されswap領域が割り当てられます。swap用のパーティションがあるのであればswapファイルは削除するとよいです。swapファイルの停止は以下の手順で行います。面倒なので以下sudoの代わりにroot権限でコマンドを発行しているものとします。

 # swapoff /swap.img
 # rm /swap.img

この後/etc/fstabよりswap.imgのマウント指示を削除して完了になります。

 

Firewallは有効化しておこう

Ubuntuの場合はインストール完了直後はFirewallが入っていないようなので、OpenSSHなどをインストールした後でFirewallを動かしましょう。RedHat系ならばfirewall-cmdを使いますが、Debian系はufwというものらしいです。

 # ufw enable 

 

ファイルサーバなのでSambaは必須

これがないとWindowsからファイル共有ができません。導入してみます。

 # apt install samba
 # ufw allow samba
 # pdbedit -a [user]

pdbeditでログインするユーザのパスワードを設定します。あと、Firewallの許可はサービス名で登録できる場合とポートを直接指定するタイプがあります。今回の場合はサービス名が使えるタイプ。firewall-cmdより簡単ですね。もちろん、 /etc/samba/smb.confの編集をしてsystemctlで再起動が必要です。

 

人によってはtelnetを使いたくなることがあるかも

通常はSSHですが、内部LANに限って簡単にアクセスするのであればtelnetもありかもしれません。Ubuntuの場合telnetはxinetd経由で起動させる方法を使います。つまり、このようにします。内部ネットワークが192.168.0系統ならば…

 # apt install telnetd xinetd
 # vi /etc/xinetd.d/telnet
 # systemctl restart xinetd
 # ufw allow from 192.168.0.0/24 to any port 23

/etc/xinetd.d/telnetはこんな感じ。

service telnet
{
    disable         = no
    flags           = REUSE
    socket_type     = stream
    wait            = no
    user            = root
    server          = /usr/sbin/in.telnetd
    log_on_failure  += USERID
}

ほかのxinetdの設定サイトでもよく見るあれです。しかし、Firewallの設定が非常に楽に見えるのは気のせいでしょうか。

 

今回の本命であるZFSの設定

これが設定できなければ意味がありません。というわけでZFSの設定です。まずはインストールから。

 # apt install zfsutils-linux

これで必要なコマンド類がインストールされます。次はZFSを設定するHDDへのパーティション設定です。通常はHDD全体をZFSに設定するのでpartedからmklabel gptで設定するだけで終わりなのですが、今回はZFS用のパーティションを作成し、そちらをZFSで設定します。

 # parted
 - select /dev/sd[c-j]
 - mklabel gpt
 - mkpart zfs[1-8] zfs 2048s -1s

今回の構成ではメインHDDがsdaとsdbに当たるのでそれ以降のsdcからsdjに対してこれを行います。前回の記事でポート番号がどれになるか確認するのはsdcがどのHDDになるかをしっかりと確認するためになります。Linux上ではこれは認識順(つまりBIOSの順番)となるのでそれほど迷うことはないと思います。ちなみに今回の場合USBメモリからインストールしようとしたためSATAカードとUSBメモリの認識が同時に行われてこの順番に割り込まれることがあったのですが…。

あとはZFSのプールを作成していくつか設定をすれば完了です。作成時にmkpartでラベルを設定しているのでそちらから設定します。

 # zpool create -f tank raidz2 zfs1 zfs2 zfs3 zfs4 zfs5 zfs6 zfs7 zfs8
 # zfs set atime=off tank
 # zfs set compression=lz4 tank
 # zfs set recordsize=1M tank

特にZFSの特性である圧縮機構を有効にするのはやっておくと容量の節約になります。単にonにするだけでもいいですが、必要であれば圧縮アルゴリズムを指定しまってもよいと思います。あとは最終アクセス時刻は基本的に使わないので書き換えをしないようにして無駄な書き込みを防ぎます。

ちなみに、今回RAIDZ(RAID5相当)とRAIDZ2(RAID6相当)を作ってベンチマークを取ってみましたが、こんな感じでした。必要であれば前回の記事の速度と比較してみてください。

RAIDZ 1GBファイル RAIDZ 4GBファイル RAIDZ2 4GBファイル
Seq-Read 4993.22
Seq-Write 2020.38
Rand-Read-512K 5729.92
Rand-Write-512K 737.395
Rand-Read-4K 258.524
Rand-Write-4K 54.959
Rand-Read-4K-QD32 67.978
Rand-Write-4K-QD32 57.255
Seq-Read 309.542
Seq-Write 593.169
Rand-Read-512K 44.064
Rand-Write-512K 585.633
Rand-Read-4K 0.707
Rand-Write-4K 17.824
Rand-Read-4K-QD32 0.729
Rand-Write-4K-QD32 17.046
Seq-Read 366.538
Seq-Write 565.193
Rand-Read-512K 20.784
Rand-Write-512K 368.535
Rand-Read-4K 0.159
Rand-Write-4K 8.108
Rand-Read-4K-QD32 0.224
Rand-Write-4K-QD32 7.591

初期設定だと1GBファイルしか作っていなかったので、どうもZFSのキャッシュ機構に引っかかってとんでもない速さでアクセスした状態になったようです。そのため、キャッシュを無効にするためにファイルサイズを4GBまで上げて再度速度測定をしています。見る限りではさすがにRAIDZ2になるとランダムアクセスが大分遅くなるようです。シーケンシャルアクセスはインタフェースカードの限界の問題もあると思うのでこんなものかな、という感じです。

ちなみに注意点としてはZFSの予備領域などの関係でいままで「48TBファイルサーバ」と書いていましたが、実際に使用可能な容量は「43TB(40TiB)」となり、予定より容量が少なくなってしまうことです。それでも今までの32TB(29TiB)よりは大分拡張されているのでまあいいか、というところでしょうか。

 

さすがに同期作業が大変…

ある程度安定動作ができるようになったのでここから旧NASサーバから新NASサーバへのデータコピーを行います。LAN経由しかないので

 $ rsync -av [旧サーバ]:[コピー元フォルダ名] [コピー先フォルダ名] 

などとしてSSH経由で引っ張り上げる位ですがなにせ32TBのサーバに入っていたデータを引き上げるので時間がかかることかかること…。

ちなみに注意点として圧縮をかけた

 $ rsync -avz [旧サーバ]:[コピー元フォルダ名] [コピー先フォルダ名] 

とする方法もあるのですが、これは「ネットワークが遅い場合」「転送元のサーバスペックが高い場合」に限られます。特にネットワークに十分な速度がある場合(両方がGbEのハブでつながっている状態など)は転送元のrsyncでCPU使用率が100%に張り付いてしまい、十分な速度が出ません。実際に私の環境では-zオプションありで30MB/sほど、-zオプションなしで60MB/s~80MB/sと2倍以上開きがありました。これを知らずにはじめに-zをつけて転送をしていたために大分時間がかかってしまいました…。

 

さて、あと何日かかるかな~

これが終わったら旧NASサーバはHDD部分を解体して新作業用サーバ(Fedora)に変身、現作業用サーバはお役御免でお疲れ様、となります。このあたりの入れ替えもまた大変な作業なのですが、まずはデータコピーが終わらないとどうしようもないですね。がんばります。