環境前提として、Proxmoxの基本的な構築が完了している必要があります。Proxmox環境の構築方法はこちらをご覧ください。また、今回は2台のノードでクラスタの構成を行います。クラスタ構成時の注意点Proxmoxのクラスタは、2台のノードから構成することが出来ます。しかしながら、HA構成にしたい場合は3台以上のノードが必要になります。また、一度クラスタに追加したノードの削除について、一度削除したノードを再登録することが出来ません。Proxmoxを再インストールする必要があります。（CLIにてProxmoxを再インストールせずに再登録する方法もあるようです）試しにクラスタを構成する場合は、これらに対して注意が必要です。クラスタ構成の利点クラスタを構成すると、各ノードのWebGUIにアクセスする必要が無くなり、単一のWebGUIからクラスタ内のすべてのノードの操作が出来るようになります。また、マイグレーションが可能になり、NFSなどの共有ストレージ上に配置されたVMであれば、ライブマイグレーションも利用可能になります。(Proxmoxではこれらの機能はすべて無償で利用できます)準備管理用のネットワークとは別に、クラスタ構成に使用するネットワークを設定することが出来ますので、必要に応じてクラスタに使用するNICの設定をしておきます。クラスタの作成まず、元となるクラスタの作成を行います。どのノードで作業してもよいはずですが、今回は「node1」と名のつけたノードで作業します。この作業は、どれか1つのノードのみの作業でかまいません。左側のメニューで「Datacenter」を選択し、「Cluster」を選び、クラスタ情報を表示します。「Create Cluster」ボタンを押します。クラスタ名を決め、「Cluster Name」に入力します。この名前は後から変更することが出来ませんので、慎重に決めてください。また、「Cluster Network」に、クラスタで使用するネットワークを設定します。複数のリンクを使用することで、Failoverなどが可能になるようです。入力が完了したら、「Create」を押して、操作が完了するのを待ちます。「TASK OK」と表示されれば、閉じて問題ありません。これで、先ほどの画面に作成したクラスタの情報が表示されているはずです。クラスタへの参加

準備今回は、Ubuntu 20.04.1 を使用しました。Ubuntuに最初から入っているドライバは使用せず、Mellanox公式から取得したドライバを使用することにします。今回は、MLNX_OFED_LINUX-5.1-0.6.6.0-ubuntu20.04-x86_64.tgzを使用しました。取得したファイルを解凍します。$ tar zxvf MLNX_OFED_LINUX-5.1-0.6.6.0-ubuntu20.04-x86_64.tgz$ cd MLNX_OFED_LINUX-5.1-0.6.6.0-ubuntu20.04-x86_64/解凍されたディレクトリの中にある、mlnxofedinstallを実行します。$ lscommon_installers.pl DEBS LICENSE RPM-GPG-KEY-Mellanoxcommon.pl distro mlnx_add_kernel_support.sh srccreate_mlnx_ofed_installers.pl docs mlnxofedinstall uninstall.sh$ ./mlnxofedinstall実行後、新しいドライバを使用するにはopenibdの再起動が必要な旨のメッセージが表示されますので、指示に従います。Installation passed successfullyTo load the new driver, run:/etc/init.d/openibd restart$ sudo /etc/init.d/openibd restartIPアドレスについて、今回は10.0.0.1/24と10.0.0.2/24を使用し、以下のように直結することにします。10.0.0.1/24 ---------- 10.0.0.2/24OSインストール時にIPアドレスの設定はしていませんので、 Interface は Down な状態になっています。そこで Interface を Up にしますが、設定を保存しておく必要はないので今回はipコマンドを使用しました。$ sudo ip link set enp65s0 upIntef

CD環境を構成したい！と、突然書いてみたわけですが、経緯を少し振り返ってみます。経緯なんてどうでもいいという場合は読み飛ばしてください。こちらで紹介したように、弊宅のオンプレ環境ではKubernetesのクラスタが動いています。こちらのブログやポートフォリオが乗っている本番環境には、Rancherを使用していますが、更新のたびにデプロイ処理を行っていました。また、コードはGithubで管理していますので、GithubへPush後、コンテナイメージを作成しローカルのコンテナレジストリにPushしたのち、Rancher側でのPodの更新が必要な状態でした。そこで、今回は、GithubへPushした後の、コンテナイメージの作成・レジストリへのPush・デプロイまでを自動化してみます。構成ざっくり図にしてみると、こんな感じになりました。Github上のmasterブランチへの変更の検知には、Webhookを使用しています。当然、Webhookを使用していますので、Rancher自体にグローバルから到達可能である必要があります。(Githubとの連携作業は、ローカルIPアドレスのみでも行うことが出来ますが、Webhookが機能しなくなります。その場合、Githubのリポジトリ設定からWebhookの宛先を修正してください。)筆者は、少し変なことをしてWebhookのみグローバルからRancherに到達可能にしています。コンテナイメージのビルドなどのフローは、Rancher自体が持つPipelineと呼ばれる仕組みを利用し、設定を行っています。この設定は、RancherのWebGUI上から行うことが出来ます。作成された設定ファイルは、(今回の場合はGithubに)pushされます。なお、Pipelineの仕組み自体に、DockerRegistryをホストする機能がありますが、今回はすでにオンプレ環境でレジストリが存在するため、そちらを使用するようにしました。もちろん、DockerHubなどのレジストリも設定可能です。このPipelineとしての設定を記したファイルは、.rancher-pipeline.ymlとして保存されます。デプロイでは、ワークロードの設定を記述したYAMLファイルを用意しておく必要があります。すでにワークロードがデプロイされている場合には、Rancher上

bashtopbashtop は、CPUやメモリ・ディスク・ネットワークといったリソースの使用状況や、プロセス一覧などを確認できるCLIツールです。同種のツールとして、 htop などが挙げられますが、 bashtop の特徴はより多くの情報を表示できる点です。インストール方法などは、 bashtop のリポジトリをご確認ください。実行してみるシェルからコマンドを叩くだけです。$ bashtop調子に乗って32C64T環境で実行したからか、表示がずれていますね。このような形で、CPU・メモリ・ディスクに加えて、プロセス一覧を見ることが出来、さらには、ネットワークの通信量も確認することが可能です。htop の場合、CPUやメモリの使用状況を確認することは出来ますが、ネットワークの通信量を確認することが出来ませんでしたが、bashtop では、これらの情報を一括で表示できています。以上、簡単にではありますが、 bashtop の紹介でした。

2023/02/12 最新のProxmoxでの変更箇所について解説記事を挟みました。Proxmox VE とはProxmox VE とは、仮想化環境を提供するプラットフォームの1つです。VM(Virtual Machine)などのホストとして使用できます。似た目的の製品として、VMWare ESXiなどがあります。こちらを利用されている方も多いのではないでしょうか。Proxmox - powerful open-source server solutionshttps://proxmox.com/ちなみに、Proxmox VE は Proxmox Virtual Environment の略です。筆者は1年以上 Proxmox VE を使用していますが、いずれも安定して動作しています。Proxmox VE の特徴大きな特徴として、VMWare ESXiと比較し、ライセンスフリーでほぼすべての機能を利用できる点が挙げられます。無償版でも、VMWare ESXiのようにVMあたりのコア数の制限はありません。また、複数のホストをクラスタリングしたり、HA環境、ライブマイグレーションといった機能も無償で利用することができます。さらに、VMWare ESXiと同様にWebインタフェースを持っていますので、Webブラウザ経由で簡単に管理することができます。Debianベースで開発されていますので、ホストOS上にRAIDコントローラのドライバなども簡単に導入することができるのも、利点といえるでしょう。さらに、VMWare ESXiでは早期にCPUサポートが打ち切られるケースがありますが、Proxmox VEでは基本的にLinux Kernelが動作可能なモノであれば動かすことができます。自宅などで古いハードウェアを利用する際には、有力な選択肢となるでしょう。VM(Virtual Machine)やLXC(Linux Container)に対応します。インストール準備公式サイトより、Proxmox VE のISOイメージをダウンロードしてください。2020年8月12日時点では、Proxmox VE 6.2 が最新でした。容量は863MBとなっています。丁度Debianのイメージと同じぐらいですね。イメージのダウンロードが完了したら、balenaEtcherやdd

さて、自宅インフラの論理構成がおおよそ固まってきたので、少し紹介したいと思います。(物理と合わせて書くとグチャグチャになるので今回はあんまり触れません。)1年ほど前の構成はこちら最近書いた物理構成はこちら指針これまでの自宅環境では、Hypervisor である Proxmox を利用した仮想化環境を主として構成していました。しかしながら、複数のWebサイトをホストしたりする都合上、仮想マシン(VM)ではスケールに手間がかかります。そこで、学習・検証を兼ねて、kubernetes を用いたコンテナ環境を採用することにしました。また、都合上、仮想マシンも同時に扱える必要がありますので、ハイパーバイザー上の仮想マシンでコンテナ環境を実現するという少し変な構成になっています。(電気代を気にしないならばマシンごとに分ければよいのですが、そうもいかないので)Server Hardware本構成では、物理サーバを3台使用しています。うち2台はHPE製の2Uサーバ、DL380 Gen10を使用し、ストレージには Western Digital 製の Ultrastar DC SS200 (SAS 12Gbps) を使用しています。Hypervisor for VirtualizationHypervisor には引き続き proxmox を利用します。VMWare ESXi を用いない理由としては、無償版においてCPU数の制限があること(8C)、ネットワークインタフェースでのLAG等が出来ないことが挙げられます。Infrastructure with kubernetes物理サーバを2台使用し、それぞれの VM 上にワーカーを乗せています。また、図にはありませんが、コントロールプレーンは物理サーバごとに1つ以上配置しています。これらの物理サーバは 10GbE 2本で接続されています。さらに、 Horizontal Pod Autoscaler による水平方向のオートスケーリングを設定しています。HTTPトラフィックは、 Ingress によるL7ロードバランサーを利用し各Podへの分散を行っています。Registry for ContainerDocker Container 用のレジストリには SUSE がオープンソースで公開している Portus を用いています。また、これらの

Docker Registryをプライベートで利用したいDocker Hub には、Docker イメージをアップロード出来る機能がありますが、アップロードしたイメージは有料会員で無い限りすべてパブリックに公開されます。つまり、Docker Hub 上においてプライベートなレジストリを利用するには、有料会員となる必要があるわけです。しかしながら、個人利用においては自身で作成したイメージをパブリックに公開したくないことも多々あります。そこで、レジストリを自身でホスティングする方法で、自分だけの Docker Registry を構築してみます。 本記事は、自宅オンプレ環境にイメージを展開するためのレジストリを構築するという目的で、TLS等での通信に必要な証明書については触れません。Docker Private Registry をDocker上で実行するDocker Private Registry 自体のイメージは、Docker Hub 上で発見することができます。また、以下のようにコマンドを利用しても検索を行うことができます。$ docker search registryNAME DESCRIPTION STARS OFFICIAL AUTOMATEDregistry The Docker Registry 2.0 implementation for s… 2984 [OK] 事前にイメージを手元にダウンロードしておきたい場合は、pull オプションを利用してください。$ docker pull registryまた、これらの手順を行わなくとも以下のコマンドを実行することで、手元にイメージがない場合は自動的にダウンロードされます。なお、本記事では、registry:latest を使用し、レジストリ用のポートとしてホストのポート5000番をbindしています。$ docker run -d -p 5000:5000 --restart always --name registry -v /mnt/docker/registry:/var/lib/registry registryここでは、Docke

Westarn Digital Ultrastar DC SS200 SAS SSD名前長いですねこちらの800GBモデルをBrand Newで手に入れたので、軽くベンチしてみました。 SAS接続モデルですので、通常のPC等のマザーボードに搭載されているSATAポートでの利用はできません。基本的なスペックは以下のとおりです。(メーカーのSpecificationより)3年ほど前の製品ですので、今時のSSDと比べると見劣りする部分はありますが、安かったので手に入れてみました。ベンチマークSAS接続モデルですので、対応したデバイスを用いました。今回はHPEのDL380 Gen10サーバを使用し、RAIDコントローラはHBAモードとしました。SAS 12Gb/sでの接続ですので、シーケンシャルについてはバス幅の理論値近くまで出ている事が読み取れます。ランダム4KなどはNVMe SSDには叶いませんが、SAS12Gbpsに対応したホットスワップベイを持つサーバにて使用する予定ですので、NVMeベイやSecondary CPUを手に入れるコストを考えると、SATAと比較してもバランスが良いと言えると思います。時間がなく簡単なベンチしかできていませんが、12Gb/s接続のSAS SSDに興味のある方の参考になれば幸いです。

色々と機材更新やらがありましたが、1年ほど書いていないなと思ったので、書いてみることにしました。前半は機器類の紹介、後半は構成についてです。自宅36Uラック私は一人暮らしをしている学生ですが、自宅に36Uラックを設置しています。その様子を先に。サーバサーバ機器はラック下部にマウントしています。重量のある機器はできるだけラック下部へ設置し、ラック自体の重心を下げるように努めています。自宅のワンルームに設置していますから、地震等でラックが倒壊する可能性をできるだけ抑えるのが目的です。 現在、以下のようなサーバがあります。名称CPURAMHP DL380e Gen8Intel Xeon E5-2420v264GBHP DL380p Gen8Intel Xeon E5-2640v2 x2128GBHPE DL380 Gen10Intel Xeon Silver 4208128GBHPE DL380 Gen10Intel Xeon Bronze 310416GB自作AMD EPYC 7452 32-Core Processor128GBネットワークネットワーク機器は主にラック上部にマウントしています。機器類の管理ネットワークは1GbEで構成し、ストレージ周りは10GbEとしています。使用しているスイッチには40GbEポートがありますから、将来的に40GbEを利用する予定です。(スイッチの紹介、検証等は別途記事にしていますので、アーカイブから御覧ください。)さらに、光ファイバーを2回線引き込んでいます。また、OpenVPNを用いたSite-to-Site VPNによって、VPS及び別のリージョンに設置した機器類について、接続を行っています。各リージョン間の経路情報の交換は、BGPを用いて行っております。 電源夏場のゲリラ豪雨等の一時的な停電・電圧降下に対応するため、1200VAのUPSを1台設置しています。昨年夏の稼働回数は、瞬間的な電圧降下によって15回ほど作動しましたので、重要な役割を担っています。また、15Aのブレーカを搭載したサーバラック用にコンセントバーを背面に設置しております。構成とか現在は、TrueNAS(FreeNAS)を用いたネットワークストレージのみが稼働している状況です。 今まではProxmoxを用いた仮想化環境をメインにしておりましたが、先日まで検

性能及び冷却性能テスト編前回、AMD EPYC Processor で2U本格水冷サーバを組んでみた。という記事を書きました。今回はその性能テスト編になります。およそ1か月近くたち、その間 Rosetta@Home 稼働のために、フル負荷で連続1か月ほど稼働させておりましたので、その評価と合わせてお届けします。(Linux環境で運用したので、Windows系のベンチマークを取るのがめんどくさくて、本記事の投稿が遅れました。)その前にタスクマネージャーの図でも。どうやら、Windows10のタスクマネージャーはそうスレッド数が64以上になると、いくらウインドウを大きくしたところでチャートは表示されないようですね。48スレッド環境では全スレッドチャートが表示されていたので。Cinebench R20CPUベンチの定番といえばこれではないでしょうか。Temperatureベンチ中の温度は40度以下でした。EPYCにはプロセッサダイが4つありますので、4ノードの温度が表示されています。なお、温度取得にはHWMonitorを利用しております。Rosetta@Homeこちらは明確なスコア等は無いので、評価のしようがないところですが、安定して1か月ほど動作しておりました。評価水冷での冷却性能や、静音性について。本サーバ機を2Uサイズながら水冷としたのには、主に2つの目的がありました。1つは、静音化です。通常、2Uサイズのサーバ機では、CPUやその他コンポーネントを十分に冷却する必要があるためにファンが高速回転し、かなりの騒音となります。しかしながら、寝室にサーバラックがありますので、出来る限り静音化しなければ安眠の妨げとなります。もう1つは、冷却性能の向上です。2Uサイズという非常に薄い空間において冷却性能を担保するには、クーラントによって熱源を移動させ、より大きなヒートシンク（今回はラジエータ）で冷却することです。まず、静音化について。本サーバ機においては、性能や発熱量に対して非常に騒音を小さくすることに成功しています。それなりに音はしますが、扇風機の強運転よりは少し静かなぐらいです。もう1つ、冷却性能について、先ほど示したように最大負荷時でもCPU温度は40度程度でした。室温は25度程度、アイドル時26度ですので、冷却性能は非常に高いといえるでしょう。なにせCPUはTDP15