このページの翻訳:
ソースの表示
管理最近の変更サイトマップ

REALFORCE R2に入替用Caps Lock/Ctrlが付いてこない件

今北産業用。

  • REALFORCE R2ではCaps Lock, Ctrlを入れ替えた時の交換用キートップはAPC付きモデルにしか付属しない。
  • 選択するモデルによっては完全互換の交換用キートップの個別入手は不可能。
  • A横CtrlだけならHHKB用キートップが使える。

以下、チラ裏。

超PayPay祭のポイント還元に釣られてREALFORCE R2を買った。初代を2台、家庭用にアイボリー、会社用に黒を持ってたりするんですけど、やっぱりR2気になるじゃないですか。だってオタクだもの。

自分は英語配列/テンキーレス/変荷重/A横Ctrl派閥に属している。R2から通常ラインナップ入りした静音モデルが気になるので、機種は自ずとR2TLS-USV-IVかR2TLS-USV-BKに定まった。アイボリーと黒、悩ましいところだが、経験的にアイボリーを選んだ。初代の両色をそれなりに使ってきて、黒には以下の難点があることが分かったからだ。

  1. キートップの印字が見づらい
  2. テカリが目立つ
  3. ホコリが目立つ

1.は完璧にタッチタイピングできる人なら問題にならないだろう。でも僕ちゃんは無理なの。特に最上段の数字キーらへん。おおむね大丈夫ではあるが、列ずれして意図しない文字が入力された時に手元を見て補正するクセがあり、その時に文字が見えないと厳しい場合がある。

2.は「アイボリー比で」という注釈が付くくらいに些細な問題ではある。REALFORCE自体、安物キーボードと比べると全くと言っていいほどテカらないが、それでもアイボリーと比べると、よく使うキーで黒はテカりが目立つ傾向にある。

3.はある意味良いこととも言えるし、逆にアイボリーは手垢が目立ったりする。経験上、手垢は気になりだすのに数か月かかるのに対し、ホコリは掃除したそばから気になりだす。

そんなわけでR2TLS-USV-IVを購入。昔ながらのツートーンの配色も割と好きだったりする。

R2到着後、さっそくCaps Lockと右Ctrlのキー設定を入れ替え、キートップも交換しようとしたら、あれれー交換用のキートップがないぞ?箱の中をひっくり返しも見当たらず。よくよくメーカーサイトで各モデルの仕様を見比べてみると、交換用キートップはAPCモデルにしか付属しないっぽい?。初代では(たぶん)全モデルに付属してたのに、そりゃないぜ東プレさんよお。

単体販売はしてないし、交換用の色付きキートップ全セットはあるけどキーボードの半値という高額設定なうえ、通常カラーがないので完全に詰んだ。

APCで変荷重なモデルって日本語配列しかないし、APC付きの英語配列は固定荷重のPFU Limited Editionしかないし、そもそも最初から詰んでた。そりゃないぜ東プレさんよお!

一応、A横Ctrl用にはHHKB用の交換用キートップ、すなわち初代REALFORCEのものが使えるらしい。

左下CapsLockはR2からの新サイズっぽいので、現状互換品は見当たらず。色(と価格)に我慢して交換用正規のキートップ全セットを買うか、APCモデルを買うしかなさそう…。

こうした細部への拘りもREALFORCEの売りの一つだと思ってたので、正直ガッカリですわ。割高でもいいから単品販売してくれないかなー。

メインPCとサーバをP2VしてRyzenおじさんからHaswellおじさんになった

住環境が変わって、メインPCと自宅サーバを同じ部屋に置くことになった。

自宅サーバは無駄に高スペックだったが(といっても逸般の誤家庭の人からは鼻で笑われる程度)、ほぼ自分専用のFreeBSDなNASやNextcloudサーバ程度にしか使ってなかった。まさに性能と電気代の無駄遣い状態。それでもPCと鯖を分けていたのは、煩い鯖を居住空間内に置いときたくなかったから(っていうのと自宅鯖という物理体に憧れがあったから。)

その制約がなくなった今──ある意味、自室にサーバを置かざるを得ない最大の制約が課されたとも言えるが、マシンを分ける意義がなくなったので、統合することにしたのが2020年10月。付けっぱなしの鯖と、寝てるとき以外はほぼ付けてるメインPCを1台にまとめれば、PCがいつでも使えるようになって電気代も節約できて一石二鳥という皮算用もあった。

その後、数々の検証と困難を乗り越え、ようやくProxmox VE基盤でメインPCと家鯖の仮想化による統合が完了した。このところ、PVEや仮想化関連の更新をしまくってたのはこのせい。旧メインPCは解体の後、パーツ類はヤフオクにドナドナされ、名実ともにRyzenおじさんからHaswell-EPおじさんにダウングレードだ😇

統合にあたっては、家鯖マシンをPVE基盤に流用した。本当はEPYCに変えたかったけどお金がないのさ…。そうは言っても、メインマシンとして使うにはCPUが心許なかったのでヤフオクお安く調達。ストレージまわりも整理した。

変更前 変更後
CPU Xeon E5-2648Lv3 (1.8GHz/12C/24T) ×2 Xeon E5-2673v3 (2.4GHz/12C/24T) ×2
SSD PM983 960GB ×2 PM963 1.92TB ×2
HDD WD80EMAZ ×2 (ミラー)
色々8TB ×4 (RAID-Z)
ST10000NM0086 ×5 (RAID-Z2)

旧メインマシンの構成は下表のとおり。

CPU Ryzen 7 1700
M/B X370 SLI Plus
RAM DDR4-3200 16GB×4 = 64GB
GPU GeForce RTX 2070 SUPER
SSD WD Black SN750 500GB (NVMe)
SSD 東芝 THNSNJ960PCSZ 960GB (SATA)
NIC ConnectX-3 Pro EN

仮想化後のマシン構造は下図のとおり。

仮想化という割には、パススルーやらRDMやらで物理とがっつり密結合してる。今後収容予定のルータは、正しく仮想マシンになる予定(SR-IOVのVFを除く)。

2ヵ月ほど使った感想としては、物理環境と遜色なく使えている。ハード的な性能は旧メイン機から間違いなく下がっており、当初こそブラウザの若干のもたつきを感じこそすれど気のせいないし慣れの範疇で、今は何の不満もない。3Dのゲームも動くし、USB DAC経由でiTunes再生、NVEncも問題なし。

(2021-03-30 追記)

改めて第10世代Coreと2070 SUPERなマシンを触ってみたら、ブラウザの表示がチョッパヤで驚いた…。P2V後のもたつきは気のせいではなかった。リンクをクリックした際、前者はまさにパッと表示が切り替わるのに対し、後者はわずかな空白期間があってからパッと出る感じ。

GPUはGeForce RTX 2070 SUPERからGTX 1650へと大幅ダウングレードしているが、これは3060への乗り換えを見越しての措置。折からのGPU不足による中古価格上昇で、2070の売却代でオトクに3060へ乗り換えるつもりだった。が、いざ蓋を開けてみると3060は微妙な感じだし、今なお2070Sの中古価格は上昇傾向だしで、正直売らなきゃよかった……。

仮想メイン環境をPVEで自動起動設定すれば、ホストマシン電源オンでゲストのWindowsも起動する。また、ゲストエージェントを入れとけば、ホストのシャットダウンも何てことはない。ゲストのブラウザからPVE管理画面を開き、ホストをシャットダウンすれば自動でWindowsのシャットダウン処理が走り、その後ホストの電源が切れる。再起動も同様だ。こうした使い勝手の面でも、物理環境と大差なくて素晴らしい。

メインマシンを仮想化する上での最大の障壁はGPUだが、Proxmox VE (KVM)を使えば難なくGPUパススルーできる。仮想BIOSの画面が物理モニタに映し出された時は妙な感動を覚えた。

USBまわりはPCIパススルーでコントローラをVMに割り当てると、普通の物理マシンの感覚で使えてよい。

今回はネットワークまわりも、SR-IOVでもって物理デバイスのように扱っている。対向のL3スイッチからはVMが直接接続されているように見え、構成的に綺麗な気がする。何よりソフトウェアブリッジを使わずに済むので、パフォーマンス的にも負荷的にも有利である。

仮想化技術さまさまですわ。

電気代削減効果はちょっと微妙かなぁ。VM起動したアイドル状態で140W程度。理想は100W切ってほしいけど、CPU 2個に32GBのRDIMM 6本、GPU/NIC/USB/U.2×2 PCIeを差してるし、むべなるかな。

状態 消費電力 メイン機
アイドル
合計
旧サーバ 待機(HDDスピンダウン) 100W 40W 140W
待機(HDD×6スピンアップ) 130W 170W
新サーバ 待機(HDDスピンダウン) 120W - 120W
待機(HDD×6スピンアップ) 140W 140W

※新サーバのHDDが5台ではなく6台なのは間違いではない。

一応、トータル30W程度の節電だけど、旧サーバのデータは不正確なので怪しいところ。1ヵ月で21kWh節電の計算となるが、現状目に見えて電気代が安くなったとかはない。在宅勤務でおうち時間が長くなってる影響が大きいのかも。今更ながら、140Wで1ヵ月だと100kWhか…馬鹿にならんな……。

その他、メイン機を仮想化した際に気になったこと、運用上の注意点は以下に箇条書きで。

  • GPUパススルー
    • ネットに転がってる解説記事に従って難なく可能
      • 一部記述が古かったり、曖昧だったりする箇所があるのは要注意
    • プライマリディスプレイが4kモニタだと、EFIからOSに制御が移った時にコケる。WUXGAモニタだと問題なし。
      • 仮想マシンの仮想BIOS表示→Windowsの起動ロゴまでは映るが、ログイン画面に切り替わるあたりで無信号状態になる。
      • それでもWindows自体は正常に起動している。
      • ROM-Bar (GPUのBIOS)を切ると、仮想BIOS→Windowsの起動ロゴは出なくなる代わりに、ログイン画面が出るようになる。
      • 仮想BIOSを弄ることは早々ないので、ROM-Barオフで運用。ログイン画面が出るまで真っ暗なのでちょっと不安ではあるけど。
      • GeForce RTX 2070 SUPER、GTX 1650で確認。ラデは知らん。
  • ネットワーク
    • ConnectX-3のSR-IOVをパススルーで利用
      • WindowsからNICとして認識されリンクアップしているものの、パケットが流れないことがある。
      • 何度か仮想マシンを再起動すると直る。一度直ればVMを落とすまで大丈夫。
      • 多少不便だけどログイン画面で判断できるので許容内。
      • なぜかiTunesのネットワークまわりの挙動が怪しい。
        • Gracenoteに繋がらない(そもそもネットワークが繋がってない判定を食らう)
        • 別マシンからホームシェアリングで繋ぎ、切断後再接続すると接続が打ち切られ、ライブラリから表示が消える。
          • iTunesを再起動すると繋がるようになる。
        • virtio-netだと問題なし。
      • VFとLinux Bridge (vmbr0)にぶら下がっている仮想NICの間で疎通できないかも?
  • USBパススルー
    • マザボのUSBコントローラをPCIパススルーでも行けるが、後付けしたUSBカードをパススルーする方が無難。
      • (IPMIの)KVMの入力がパススルー先のVMに持っていかれ、KVMが用を成さなくなるから。
        • 仮想マウスと仮想キーボードは内部的にUSB接続されているのだ。
        • いざという時に困る(PVEのWeb UIが応答しなくなって、物理ターミナル経由でrebootしなきゃいけないときとか)
      • マザボのUSBはPCIデバイス的にはUSB 2.0/3.0が別々に認識され、片方のみパススルー設定できるが、結局両方ともパススルーされる模様。
  • スリープ、ダメ、ゼッタイ
    • VM(のWindows)をスリープさせたが最後、復帰できなくなるのでスリープさせてはいけない。
      • 少なくともパススルーしてるUSBマウス・キーボードをガチャガチャでは復帰せず
      • PVEの管理画面から何か叩けば行けるかも?
    • モニタのスリープは大丈夫。
1)
Forwarding Database Entry

SuperWorkstation 7048A-Tのファンリスト

SuperWorkstation 7048A-T (SuperChassis 743TQ-1200B-SQ)で使われているファンの備忘録。

  • CPUファン (SNK-P0050AP4)
    • Nidec UltraFlo T92T12MS3A7-57T07
      • 92mm×25mm
      • 12V 0.35A
      • 7枚羽
      • 型番の命名規則から読み解くと、NBRXタイプの回転数カスタム仕様のSupermicro向け特注品っぽい。
  • 背面ファン
    • Nidec UltraFlo T92T12MHA7-57T071
      • 92mm×25mm
      • 12V 0.14A
      • 7枚羽
      • NBRXタイプ/高回転数/特注品
  • 前面ファン
    • 未確認
    • コネクタはMolex 51191シリーズの4ピン(51191-0400)

デグレったZFSプールは他マシンでのインポートが制限されるっぽい?

色々と事情があって、FreeBSDで作ったHDD×4台からなるRAIDZプールを、HDD×3でデグらせた状態でZoL環境でインポートした。

すると自動scrubが走るわけだが、処理途中で一旦エクスポートし、FreeBSDの方でHDD×4の状態でインポートしようとしたら出来なかった。

# zpool import zdata
cannot import 'zdata': no such pool available

こんなエラーが出るわけ。プールをFreeBSDとLinuxの間で、あまつさえデグレった状態で行き来させたせいで壊れた!?と超焦るわけ。

ZoL環境だと正常にインポートできたのでプールの無事は確認でき、HDD×4に戻してRAID修復が終わるのを待ったところ、FreeBSDの方でも何事もなくインポートできるようになった。

ここから分かることは、どうやらデグレった状態のプールを一度でもインポートすると、プールの健全性が回復するまで別のシステムでのインポートができなくなるらしい?これがZFSの正常な挙動なのか、FreeBSD (Legacy ZFS)とZoLを行き来したが為の特殊挙動なのかは分からない。

もし正式挙動だとしたら、プール修復中にマシンが壊れるとプールが死ぬわけだから、正式挙動ではないとは思うんだけど、実際に起こった事象として記録しておく。

ディスクがどのzpoolに所属していたか調べる

複数のHDDを抜き差ししてると、どのHDDがどのzpoolの構成員か分からなくなる事がある。ちゃんと管理しとけって話だが、そんな時はzdb -lでZFSのラベル情報を表示すればよい。

ProxmoxVE (ZFS on Linux)での実行なので、デバイス名はsdXになっている。

# zdb -l /dev/sdh1
------------------------------------
LABEL 0
------------------------------------
    version: 5000
    name: 'zdata' ★これ
    state: 0
    txg: 23527188
    pool_guid: 15920220212014191793
    hostid: 1525007054
    hostname: 'hostname.example.com'
    top_guid: 1118325231086088749
    guid: 9773797371878116701
    vdev_children: 1
    vdev_tree:
        type: 'raidz'
        id: 0
        guid: 1118325231086088749
        nparity: 1
        metaslab_array: 34
        metaslab_shift: 37
        ashift: 12
        asize: 31989740601344
        is_log: 0
        create_txg: 4
        children[0]:
            type: 'disk'
            id: 0
            guid: 3334618698730764157
            path: '/dev/ada5p1'
            phys_path: 'id1,enc@n3061686369656d31/type@0/slot@3/elmdesc@Slot_02/p1'
            whole_disk: 1
            DTL: 291
            create_txg: 4
        children[1]:
            type: 'disk'
            id: 1
            guid: 4503436449772901953
            path: '/dev/ada3p1'
            phys_path: 'id1,enc@n3061686369656d31/type@0/slot@1/elmdesc@Slot_00/p1'
            whole_disk: 1
            DTL: 290
            create_txg: 4
        children[2]:
            type: 'disk'
            id: 2
            guid: 9773797371878116701
            path: '/dev/ada2p1'
            phys_path: 'id1,enc@n3061686369656d30/type@0/slot@3/elmdesc@Slot_02/p1'
            whole_disk: 1
            DTL: 289
            create_txg: 4
        children[3]:
            type: 'disk'
            id: 3
            guid: 1033141966906037929
            path: '/dev/ada4p1'
            phys_path: 'id1,enc@n3061686369656d31/type@0/slot@2/elmdesc@Slot_01/p1'
            whole_disk: 1
            DTL: 288
            create_txg: 4
    features_for_read:
        com.delphix:hole_birth
        com.delphix:embedded_data
    labels = 0 1 2 3

注目すべきはnameの項目で、プール名がそのまんま入っている。さらに他の項目からプールの詳細がわかる。

  • name:
    • プール名
  • hostname
    • プールを作成したホスト名
  • vdev_tree: type
    • プールの構成方法
  • vdev_tree: children
    • vdevを構成するストレージの数
  • vdev_tree: children: path
    • プール構成ストレージとして最後に認識された時のデバイスパス

これらを読み解くと、/dev/sdh1は「FreeBSDマシン2)hostname.example.comで作られた4台構成のRAID-Zプールzdata」の構成デバイスだった、ということが推測できる。

2)
pathのadaXから推定
start.txt · 最終更新: 2019-08-19 02:45 by Decomo
CC Attribution-Noncommercial-Share Alike 4.0 International
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0