top

概要今回は、ElastiFlow 環境を構築してネットワークのフロー情報の収集と可視化を行う環境を構築してみます。OS は Ubuntu22.04 LTS です。ElastiFlowとはElastiFlow とは、ネットワークのフロー情報を解析するためのツールの1つです。OSS として提供されており、データの蓄積と解析を行う ElasticSearch 、データを可視化する WebUI を提供する Kibana を合わせて使用することでフロー情報の取得から解析・可視化を行うことができます。この ElasticSearch に対して収集したデータを入れるツールとして以前は logstash が用いられていたようですが、今は ElastiFlow に内包された ElastiFlow Unified Flow Collector によってデータの収集と ElasticSearch 用データ形式への正規化が行われています。準備最初に、構築にあたって動作に必要なスペックを確認しておく必要があります。フロー情報の分析などにそこそこの計算資源を消費しますので、公式サイトを参考にマシンスペックを決定します。また、必要になる基本的なツールをインストールしておきます。sudo apt install apt-transport-https unzipLinux KernelのチューニングElasticSearch はデフォルトで mmapfs ディレクトリを使用してデータを保存しますが、Linux のデフォルトの制限値が低すぎるためこの制限を 262114 に引き上げておく必要があります。echo "vm.max_map_count=262144" | sudo tee /etc/sysctl.d/70-elasticsearch.conf > /dev/nullまた、ネットワーク関係のパラメーターについても変更を行います。デフォルトでは大量の UDP パケットの受信に最適化されておらずパケットがドロップされる可能性があるため、チューニングを行っておく必要があります。echo -e "net.core.netdev_max_backlog=4096\nnet.core.rmem_default=262144\nnet.core.rmem_max=67

image not found

概要前回、NVMe over RDMA 環境を構築し、簡単な動作確認を行いました。今回は、前回の概要でも触れたとおりNVMe over TCP を試してみます。NVMe over TCP はその名の通り、NVMe プロトコルを TCP プロトコル上に流すことでリモートでの利用を可能にしたものです。NVMe over RDMA (RoCEv2) と異なり、一般的な TCP プロトコルを使用しているため専用のスイッチなどを必要としないメリットがあります。しかしながら、メモリ上のデータを直接扱う RDMA の恩恵を受けられないため、プロトコルスタックの処理によるCPU負荷の上昇やIOに対する遅延の増大、スループットの低下などのデメリットも存在します。今回はそんな NVME over TCP 環境を構築し、動作確認を行ってみます。環境今回の検証に使用した環境です。マシンは2台用意し、それぞれをターゲット(Server)側、Initiator(Client)側としています。ターゲット側詳細MachineHPE ProLiant DL380 Gen10CPUIntel Xeon Silver 4208 x2MemoryDDR4 ECC RDIMM 128GB (16GB x8 2400MHz)NICMellanox ConnectX-4 100Gb(Ethernet) MCX415A-CCATNVMeIntel DC P4600 1.6TB U.2 x2OSUbuntu Server 22.04 LTSInitiator側詳細MachineFujitsu Primergy RX2540 M4CPUIntel Xeon Gold 6148 x1MemoryDDR4 ECC RDIMM 128GB (32GB x4 2666MHz)NICMellanox ConnectX-4 100Gb(Ethernet) MCX415A-CCATOSUbuntu Server 22.04 LTS準備今回も、前回と同様に SPDK を用いて環境構築を行います。SPDK をビルドし nvmf_tgt が実行可能な状態までは前回と同様の手順です。ネットワーク設定この段階でネットワーク設定を行っておきます。手順については省略します。なお、今回は次のような構成にしています。なお、リンクスピードは100Gb

top

概要近年、NVMe over Fabric (=NVMeoF) という言葉をよく聞くようになりました。この Fabric 自体は NVMe のプロトコルをネットワーク上に流すことでリモートホスト上からターゲットホストの NVMe Disk に直接IO操作を行うものです。同じような目的を持ったプロトコルとしては iSCSI などがあげられます。しかし、SCSI 自体が近年目覚ましく進化したフラッシュストレージ (=SSD) の性能に追いつけていないのが現状です。この問題に対処するため、より効率的なプロトコルとして新たに NVMe プロトコルが策定されました。NVMe over Fabric は効率的な NVMe プロトコルを利用することにより iSCSI よりも高速にIOを裁くことができるメリットがあり、注目されています。NVMe over Fabric は通信に使用するプロトコルとして Infiniband や Ethernet 、さらには FibreChannel を選択することができます。加えて、RDMA(=Remote Direct Memory Access) などの技術を用いることでより高速・低遅延を実現しています。RDMA 自体は Infiniband の技術です。しかし、RDMA を Ethernet 上で利用するための技術として、RoCE (RDMA over Converged Ethernet) があります。この RoCE は v1 と v2 が存在し、RoCEv1 は Link Layer のプロトコルであるため異なるネットワークセグメント間において接続することができませんでした。しかし RoCEv2 では Internet Layer のプロトコルとなったため、ルーティングが可能となり、異なるネットワークセグメント間においても使用することができるようになりました。まとめると、低遅延でかつより高速にリモートホスト上の NVMe にアクセスするための技術として、NVMe over RDMA があり、これを Ethernet 上で利用するために RoCEv2を用いる必要があるということです。また、RoCE 自体は途中経路上のスイッチにも設定が必要です。このため、RDMA を用いずに TCP で直接接続するプロトコルとして、NVMe over TCP

top

背景前回はお借りした機材を利用して100GbEをテストしました。今回は、手元に Mellanox ConnectX-4 があったので、こちらを再度簡単にテストしてみることにします。検証機材今回は、NICとケーブルを前回と異なるものでテストします。(ちなみに前回はお借りした機材でしたが今回はすべて私物です。)詳細MachineFujitsu Primergy CX2550 M2CPUIntel Xeon E5-2690v4 x2MemoryDDR4 ECC RDIMM 128GBNICMellanox ConnectX-4 100Gb(Ethernet) MCX415A-CCATCableIntel QSFP28 100G-CWDM4 module (SPTSBP2CLCKS)OSUbuntu Server 20.04.4 LTSMellanox ConnectX-4 MCX415A-CCATIntel QSFP28 100G-CWDM4 module準備初めに、ドライバをインストールします。手順は前回と同様です。Mellanoxのドライバは公式サイトからダウンロードできます。IPアドレスについて、前回と同様に 10.0.0.1/24 と 10.0.0.2/24 を使用し、以下のように直結することにします。10.0.0.1/24 ---------- 10.0.0.2/24設定はnetplanを用いて行いました。2つのNIC間は100G-CWDM4モジュールとシングルモードファイバー(duplex)を用いて接続しました。リンクアップを確認ethtool コマンドを用いて、100Gbpsでリンクアップしているか確認します。$ ethtool ens11np0Settings for ens11np0: Supported ports: [ FIBRE ] Supported link modes: 1000baseKX/Full 10000baseKR/Full 40000baseKR4/Full 40000baseCR4/Full

top

この記事は、CyberAgent 22 新卒 Advent Calendar 2021の19日目の記事です。さいごに概要本記事では、自宅でサーバーやネットワーク機器を運用する筆者が、普段の運用をどのように行っているかを紹介します。また、後半では運用していく中で発生したトラブル経験などを紹介します。サーバーとはサーバーと言われてどのようなものを想像するでしょうか。一般的に、自宅サーバーなどと言われると自宅に中古のデスクトップPCなどを用意してサーバーとして運用するような形を想像する方が多いと思います。しかし、コンピューターにはサーバー用に設計されたものが存在します。これらはデータセンターなどで運用され、サイズ等が規格化されておりラックサーバーなどと呼ばれています。また、これを搭載するための専用のラックが存在しており、ユニット数(U)でいくつかの種類があります。このラックを使用することで、上方向へ積み上げてサーバーを設置することが可能になります。ラックサーバー自体は当然、一般家庭に設置することを想定したデバイスではありませんから、静音性より冷却性能の方が重要です。そのため、基本的に静音性とは無縁です。(サーバーラックに搭載されたラックサーバーの例)自宅サーバーを運用するメリットでは、デスクトップPCなどを使用する場合を含め自宅でサーバーを運用するメリットは何でしょうか。まず一つ目は、学習機会を得られるということです。AWSやGCPといったパブリッククラウドを利用するのと違い、自宅でサーバーを運用するには、物理レイヤーからすべて自分で設計や構築を行う必要があります。パブリッククラウドが普及した近年では、手間が掛かる事から嫌厭されがちですが、学習することに重点を置けば、より多くの学習機会が得られるというメリットがあると言えます。その中では、ネットワークに関する知識のほか、ハードウェアに関する知識も必要となります。そして、こういったレイヤーの知識は経験も重要です。この経験は、実際に運用していく中で原因切り分けなどを実施することで身に付く部分が多い分野でもあります。もう一つは、シビアにコストを気にする必要が無くなるということです。パブリッククラウドでは、インスタンスの起動時間や通信量による課金でコストが掛かります。例えば、パッケージを再インストールしたい場合などに、追加でコスト

top

概要本記事では、Ubiquiti Networks社が提供するEdgeRouter製品でIPv6トンネル接続を行った場合のスループットについてまとめます。検証機器次のリストに示すデバイスでテストを行いました。検証環境検証に使用するトンネル接続には、IPIP6及びIP6GREを使用し、スループットの計測はiperf3を使用して計測を行いました。構成はローカルでP2Pで接続されたIPv6ネットワーク上に検証機器で示したデバイスを接続しています。また、対向のデバイスは一般的なラックマウントサーバにVyOSをインストールして使用し、計測上のボトルネックとならないことを確認しています。なお、都合上、検証機器上にiperf3サーバを立てる形で計測しています。そのため、多少の負荷がルータにかかる状態である点に注意してください。計測結果ModelIPIP6IP6GRE備考:CPUEdgeRouter-X136Mbps138MbpsMediaTek MT7621AT (880 MHz, 2 cores)EdgeRouter-Lite85Mbps84MbpsCavium CN5020 (500 MHz, 2 cores)EdgeRouter-8243Mbps246MbpsCavium CN6120 (880 MHz, 2 cores)EdgeRouter-4912Mbps914MbpsCavium CN7130 (1 GHz, 4 cores)まとめ計測結果より、搭載されているCPUの世代やクロックがスループットに大きく影響していることが読み取れます。加えて、EdgeRouter-4はファンレスで消費電力もEdgeRouter-8と比べると各段と少なく、とにかく性能が欲しい場合には選択肢の1つとなるでしょう。もちろん、国内でも容易に入手可能で安価なEdgeRouter-Xでもそれなりのスループットが確保できると言えるため、選択肢として十分有力でしょう。参考になれば幸いです。

top

概要フレッツ光を契約し、フレッツ・v6オプションを申し込むことで利用できるNGN網内での通信について、RTT(ラウンドトリップタイム)を計測したので、その結果をまとめます。計測環境なお、拠点「KYT-A」及び拠点「KYT-B」については、地理的状況から同じ局舎へ収容されているものと推定しています。加えて、諸事情により全拠点間を網羅的にテストはしていません。計測方法京都府内での計測結果まず、地理的に同じ局舎へ収容されていると推定される拠点「KYT-A」と拠点「KYT-B」間での計測結果が次のようになります。$ sudo ping6 240b:250:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX -c 10PING 240b:250:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX(240b:250:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX) 56 data bytes64 bytes from 240b:250:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX: icmp_seq=1 ttl=61 time=2.35 ms64 bytes from 240b:250:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX: icmp_seq=2 ttl=61 time=2.23 ms64 bytes from 240b:250:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX: icmp_seq=3 ttl=61 time=2.80 ms64 bytes from 240b:250:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX: icmp_seq=4 ttl=61 time=2.38 ms64 bytes from 240b:250:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX: icmp_seq=5 ttl=61 time=2.39 ms64 bytes from 240b:250:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX: icmp_seq=6 ttl=61 time=2.42 ms64 bytes from 240b:250:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX: icmp_seq=7 ttl=61 time=2.97 ms64

image not found

概要本記事では、Ubiquiti Networks社が提供しているEdgeRouterにおける、IPIP6トンネルやIP6GREトンネルの設定について、例を示します。なお、EdgeRouterで使用されるEdgeOSのバージョンは v2.0.9-hotfix.1 を使用したものです。IPIP6IPIP6はIPv4 over IPv6となります。IPIP6の設定例は次のようになります。set interfaces ipv6-tunnel v6tun0 address 10.0.0.0/31set interfaces ipv6-tunnel v6tun0 encapsulation ipip6set interfaces ipv6-tunnel v6tun0 local-ip 'fd00::1'set interfaces ipv6-tunnel v6tun0 remote-ip 'fd00::2'上記の設定項目については、次のようになります。address v6tun0が持つトンネル内の終端IPアドレスを指定します。encapsulation トンネル方式を指定します。この例ではipip6を使用します。local-ip トンネル接続に使用する自IPv6アドレスを指定します。remote-ip トンネル接続に使用する対抗側のIPv6アドレスを指定します。上記設定を施したのち、 show interfaces ipv6-tunnel を実行した結果を以下に示します。ipv6-tunnel v6tun0 { address 10.0.0.0/31 encapsulation ipip6 local-ip fd00::1 remote-ip fd00::2}IP6GREIP6GREの設定例は次のようになります。set interfaces ipv6-tunnel v6tun0 address 10.0.0.0/31set interfaces ipv6-tunnel v6tun0 encapsulation ip6greset interfaces ipv6-tunnel v6tun0 local-ip 'fd00::1'set interfaces ipv6-tunnel v6tun0 remote-

image not found

概要本記事では、VyOSとEdgeRouterそれぞれにおいてBGPを設定する場合の設定項目の差異と、挙動の違いについてまとめます。隅々まで調査したわけではなく、利用する中で判明した点をまとめたものですので、完璧ではないことを予めご理解ください。VyOSVyOSとは、オープンソースで提供されるソフトウェアルータです。Debianをベースとして開発されており、ルーティングなどのネットワークの基本的な機能から、各種VPNプロトコルやトンネリングプロトコルなどを扱うことが出来ます。vyos.ioEdgeRouterEdgeRouterは、Ubiquiti Networks社が発売しているネットワーク機器のブランドです。低価格でありながら高機能であり、またライセンス料などが発生しないという特徴を持つ製品です。中身はVyOSベースとなっているようなので、基本的にVyOSのドキュメントを参考にすることが出来ます。本記事では、EdgeOS v2.0.9-hotfix.1 を例に取り上げていきます。BGP設定周りのコマンド体系VyOSでは1.2系列からBGP設定周りのコマンド体系が一部変更となっています。例えば、広報するネットワークを明記する場合、VyOS 1.2系以降では次のように記述します。set protocols bgp address-family ipv4-unicast network 192.168.1.0/24しかし、VyOS 1.1.8以前、またはEdgeRouterにおいては、address-family の下に ipv4-unicast という設定項目は存在しません。したがって、VyOS 1.1.8以前、またはEdgeRouterにおいては次のように記述する必要があります。set protocols bgp 65001 network 192.168.1.0/24network項目で設定したネットワークの広報動作の違い上記で例を示した network で指定した広報したいネットワークの広報動作についても、VyOSとEdgeRouterで挙動の違いがみられます。VyOSの場合、こちらのページに次のような記述があります。By default, the BGP prefix is advertised even if it’s not present in the

image not found

2021/01/09 インスタンスにパスワードを設定する箇所の誤りを修正しました。kolla-ansibleとは公式ページOpenStack 環境のデプロイメントツールです。更に、完全にカスタマイズ可能であることも大きな特徴です。加えて、CentOS や Ubuntu などの多くの Linux ディストリビューションに対応しているのも大きな特徴と言えます。なお、デプロイには Ansible が利用されます。他にも devstack や microstack など数多くのデプロイメントツールが存在しますが、これらは開発環境向けで、カスタマイズが困難であったり、再起動したら壊れてしまうものなど、扱いにくいのが現状です。また、 kolla-ansible と同様に Ansible を利用して OpenStack 環境の構築を行う openstack-ansible なども存在しますが、こちらも筆者環境での検証では再起動したら壊れてしまうものでした。そこで、今回は kolla-ansible を利用してみることにしました。なお、 kolla-ansible ではすべてのコンポーネントを1つのサーバ上で動作させる all-in-one 構成と、複数のサーバをクラスタリングして利用する multinode 構成を選択することができます。今回は all-in-one 構成を構築してみます。multinode 構成については、次回以降取り扱う予定です。インストール準備kolla-ansible では CentOS や Ubuntu などを利用することができますが、本記事では Ubuntu 20.04 LTS を利用しています。事前に python3 などを用意しておく必要がありますので、必要なパッケージとともに導入します。$ sudo apt update$ sudo apt install python3-dev libffi-dev gcc libssl-dev$ sudo apt install python3-pipインストールされた pip3 が最新バージョンであるか確認します。$ sudo pip3 install -U pip続いて、 Ansible をインストールします。$ sudo apt install ansiblekolla 及び kolla-ansible

top

環境前提として、Proxmoxの基本的な構築が完了している必要があります。Proxmox環境の構築方法はこちらをご覧ください。また、Cloud-init Supportを参考にしています。Cloud-initテンプレートの準備本記事では、VMで使用するOSとしてUbuntuを使用します。https://cloud-images.ubuntu.com/でOpenstack向けのCloud-initに対応したイメージが配布されていますので、こちらを利用します。Proxmoxホストのシェルにログインして、上記イメージをダウンロードします。今回はUbuntu 20.04 LTSを使用しますので、こちらをダウンロードしました。# wget https://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64.img続いて、テンプレートで使用するためのVMを作成します。# qm create 9000 --memory 2048 --net0 virtio,bridge=vmbr0先ほどダウンロードしたイメージをインポートします。以下の例では対象ディスクをlocal-lvmとしていますが、適時変更してください。(local-zfsなど)# qm importdisk 9000 focal-server-cloudimg-amd64.img local-lvmインポートしたディスクをscsi0としてVMにアタッチします。先ほどと同様に、local-lvmやvm-9000-disk-0は環境によって異なる場合がありますので、適時変更してください。# qm set 9000 --scsihw virtio-scsi-pci --scsi0 local-lvm:vm-9000-disk-0続いて、Cloud-initが利用するCDROMドライブを設定します。# qm set 9000 --ide2 local-lvm:cloudinit先ほどアタッチしたディスクをブートディスクとして設定します。# qm set 9000 --boot c --bootdisk scsi0Cloud-initはシリアルコンソールを使用するため、その設定をします。# qm set 9000 --serial0 socket --

top

4Kゲーミング2020年9月17日に、NVIDIAのAmpereアーキテクチャを採用したGPU、RTX 3080が発売解禁されました。筆者は、深夜販売に突撃して運よく入手出来たので、4Kゲーミング性能について軽くベンチマークを通して見ていきます。RTX 3090 ?RTX3080に続いて、RTX 3090が2020年9月24日に発売解禁となりました。こちらも深夜販売での抽選に参加したところ運よく入手できましたので、こちらも見ていきます。なお、「コスパ」とか言ってはいけません。筆者が泣いてしまいます。ベンチマーク環境ベンチマークには、おなじみ3DMarkを使用します。また、DLSSについてもどのような効果があるのか気になったので、こちらも試してみます。手持ちのゲームでDLSSに対応したゲームが「DEATH STRANDING」ぐらいしか無かったので、参考程度にご覧ください。ベンチマークPCとしては以下のものを使用しています。詳細CPUAMD Ryzen9 3950X 16-Core ProcessorM/BASUS Pro WS X570-ACEMemoryDDR4 Non-ECC UDIMM 16GB x4(64GB) 3200MHzPSU80PLUS GOLD 750WStorageWestern Digital SN550 500GB (M.2 NVMe)GprahicsMSI GTX 1080 AERONVIDIA RTX 2060 FEMSI RTX 3080 GAMING X TRIOZOTAC RTX 3090 TrinityRTX 2000シリーズとの比較ベンチを多く見ますが、GTX世代との比較があまりなされていないように思ったのと、筆者がGTX 1080からの更新のため、GTX 1080との性能差に注目したいところです。また、手持ちにあるGPUの中にRTX 2000シリーズがRTX 2060しか無かったので、参考程度です。RTX 3080 and RTX 3090RTX 3080 FERTX 3090 FECUDAコア8704基10496基RTコア68基82基Tensorコア272基328基ベースクロック1.44GHz1.4GHzブーストクロック1.71GHz1.7GHzVRAM10GB GDDR6X24GB GDDR6X外観ZOTAC RTX 30

top

環境前提として、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」と表示されれば、閉じて問題ありません。これで、先ほどの画面に作成したクラスタの情報が表示されているはずです。クラスタへの参加

top

準備今回は、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

top

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上

top

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

top

2020/12/29 無償版リポジトリを設定するを最新情報に更新し、目次を追加しました。2021/12/19 本記事は Proxmox VE 6.2 によるものです。Proxmox側のアップデートによりUIの一部変更や設定手順の簡素化などが発生しているため、近日中に情報を更新します。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日時点では、Prox

top

さて、自宅インフラの論理構成がおおよそ固まってきたので、少し紹介したいと思います。(物理と合わせて書くとグチャグチャになるので今回はあんまり触れません。)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 を用いています。また、これらの

image not found

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

top

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に興味のある方の参考になれば幸いです。

top

色々と機材更新やらがありましたが、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を用いた仮想化環境をメインにしておりましたが、先日まで検

top

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

top

事の発端巷で話題になっていた [email protected] の方を自宅ラック内の設備の一部を使用して動かしておりましたが、当然CPUを使い切るわけですから、それなりに電力を消費することになります。Haswell世代のXeon E5 プロセッサを始めとして、100スレッド超えの計算能力を突っ込んでいました。(一時期、[email protected]において国内2位の計算能力を提供していました。)しかしながら、それだけ電力使用量も増えるもので、Haswell世代のXeon E5 プロセッサを2基(計24コア48スレッド)積んだマシンを動かすと、それだけで400W近い電力を消費していました。それ以外にも多くのマシンを動かしていましたから、1.5KWh近い電力を消費していたように思います。(流石にここまで来ると、部屋が暑くなります。まだ4月でしたので、窓を開けてちょうどいい感じでした。)自宅ラック勢の中では、比較的新しいマシンが多い弊宅(当社調べ)ですが、それでも計算能力に対して電力効率が、決していいとは言えないことが気になってきます。ここまで来ると、より良いものが欲しくなるのが人の性。AMD EPYC プロセッサ、中でもZen2アーキテクチャを採用したRomeに目をつけました。 構成を考えるまず、筐体(ケース)ですが、弊宅の36Uサイズの19インチサーバーラックへインストールするため、2Uサイズのラックケースを選択しました。そうすると、高さが80mm程度を低いため、市販品のCPUクーラーは入らなくなります。当然、サーバー向けプロセッサですから、2Uサイズの空冷CPUクーラーも存在します。しかしながら、TDPが150Wを超えるようなプロセッサを2Uサイズに収まるような小さな空冷CPUクーラーで冷却したところで、冷却能力を高めるためにファンが高速回転しうるさくなるか、ファンの回転数を落としたために冷却不足になるなど、冷却や音の問題が出てきます。弊宅はワンルームですから寝室を兼ねていますし、極力音は小さくしたいものです。そこで、思い切って水冷にしてみることにしました。クーラントによって熱を移動させ、2Uサイズの空冷クーラーよりは大きな断面積を確保したラジエータによって冷却するのです。本格水冷自体始めてで、どの程度冷却できるか、静音性等は未知数でしたが、チャレンジしてみることとしました。

image not found

知り合いが、増設したHDDを認識しない現象に見舞われ、トラブルシューティングしたのでそのログです。軽く調査を行ったところ、Seagate製のHDDにおいて稀に発生するようです。原因調査中、思ったように情報にたどり着けなかったので、記しておきます。予め申しておきますが、本記事はSeageteさんに対する批判等ではございません。(解決方法が知りたい人は、この記事の下部へ)Windows10PCにHDDを増設するも認識しない!?BIOS上には増設したHDDが表示され、Windows10上のデバイスマネージャー上でも、増設したHDDは認識されていました。しかしながら、増設したHDDを使用するにはMBRないしはGPTのパーティションテーブルを作成する必要があります。通常、Windows10ではこれらの操作はディスクの管理から行うこととなります。しかし、肝心のディスクの管理には当該HDDは表示されていませんでした。 ちなみに、CrystalDiskInfoでは認識し、S.M.A.R.T.情報を読み取ることができる状態でした。これは、接続ケーブルの不良やマザーボードの故障ではないことを意味します。新品なのにHDD上になんか残っている…?調べてゆくと、Windows10上で記憶域プールとして認識されたものは、ディスクの管理に表示されないことがわかります。今回の症状に合致します。(そのような設定を行ったかどうかは別として…) 解決方法…?そこで、Windows10上から記憶域プールの設定を確認します。(設定へのたどり着き方は各自調べてください。 設定 から行く方法と、コントロールパネルから行く方法があります。)本件の場合、他人のPCだったのでスクリーンショットがありませんがディスクの管理に表示されないディスクが、記憶域プールとして使用されていました。すでに記憶域プールを利用している方は、操作を行うディスクを間違えないように注意しながら、この記憶域プールを削除します。 本件においては、以上の操作を行うことで、ディスクの管理上に表示されるようになりました。 *当該操作等を行ったことによるデータの喪失その他について、当記事の筆者は何ら責任を負いません。原因は?本症状は稀に発生することが多いようで、大抵の場合返品交換をしてもらうことで解決しているようです。また、その殆どがSeagat

top

さておよそ半年前、MikroTik社のCRS326-24S+2Q+RMを購入した記事を書きましたが、40GbEのテストは後でやると書きました。ようやくそのテストを実施する(気になる)ことができたので、その結果を記していきたいと思います。環境本当はLinux機でテストしたかったのですが、ぱっと使えるマシンがWindowsしかなかったので、諦めてそちらでテストを行いました。マシン2 (HPE DL380 Gen9)なお、Desktop機においてはNICが冷却できずに燃えそうだったので、サーキュレータの風をぶち当てて強制冷却することにしました。PC1 --- CRS326-24S+2Q+RM --- PC2こんな構成でテストを行いました。なお、IPアドレスについては別途DHCPサーバからの配布としました。iperf3 with MTU 1500$ ./iperf3.exe -c 192.168.5.111Connecting to host 192.168.5.111, port 5201[ 4] local 192.168.5.110 port 51729 connected to 192.168.5.111 port 5201[ ID] Interval Transfer Bandwidth[ 4] 0.00-1.00 sec 1.01 GBytes 8.71 Gbits/sec[ 4] 1.00-2.00 sec 963 MBytes 8.07 Gbits/sec[ 4] 2.00-3.00 sec 965 MBytes 8.09 Gbits/sec[ 4] 3.00-4.00 sec 1.06 GBytes 9.07 Gbits/sec[ 4] 4.00-5.00 sec 1.14 GBytes 9.76 Gbits/sec[ 4] 5.00-6.00 sec 1.13 GBytes 9.74 Gbits/sec[ 4] 6.00-7.00 sec 1.06 GBytes 9.10 Gbits/sec[ 4] 7.00-8.00 sec 1.10 GBytes 9.41 Gbits/sec[ 4] 8.00-9.0

2019年を振り返って

2019/12/31 23:30

top

さて、もう2019年も終わろうとしている大晦日、今年もあと2時間ちょっとで終わる今2019年の振り返りをして見ようと思います。読んでもなんの特にもならないので、今すぐブラウザバックしてテレビでも見たほうがいいんじゃないでしょうか。途中なんかどうでもいいという人は、この記事の一番下にまとめてあります。 1月自分でも覚えてないんで、自身のツイートを漁って見てたのですが、何してんだこいつってなりましたね。1月真ん中らへん、VMWare ESXiを触ってみてたみたいですね。 自分の記憶にあるのは、とりあえず1Uサーバーにインストールして触ってみたところまでです。結局その後Proxmoxを採用しましたので…。 そして、Twitterでたちまち話題となった「例のグラボ」こと、マイニング向けのRX470 8GB。こいつの映像出力端子を有効化して遊んだりしてました。 1005という規格の1mm x 0.5mmサイズのパーツを付ける作業を手作業でしてみたくて、買った感じですね。その後このグラボは部品箱へと入ってゆきましたとさ。 そして、人生初の新品サーバー、FujitsuのPrimergy RX1330 M1を購入した月でもありました。3万ぐらいで買えたのでお得だったなと。2月先程紹介したサーバー、やっとここで開封したらしいです。何やってんだ。 そして、ラックに入れてたらしいですね。このときのラックはまだ24Uでした。(ということは後ほど何かが起こります。) そして、2月中旬頃から休暇期間に入ったはずなのに、ツイッターばかりしていて進捗が見つかりませんでした。(?)この時期に、今の構成(iSCSIを用いたストレージシステム)の基礎ができたように思います。 3月どうやらいい加減ネットワークをちゃんとやろうと思って、ルーティング周りの勉強(と言っても実際に設定して動作させるところまで)をしていたように思います。そして過去の自分は「OSPFとBGP完全に理解した」とか言っていますね。ホントかな?????? そして、知り合い宅のとの間にVPNを張ってBGPやる作業をした記憶があります。 また、それまで宅内のサーバーはHPのProLiant DL360 G7を3台+αとして運用してましたが、この時期からGen8へのリプレイスを始めました。Gen8がそれなりにお安く買えるよう

top

40GbE対応スイッチMikroTikから発売された、世界最安の40GbE対応スイッチとも言える CRS326-24S+2Q+RMを手に入れたので紹介します。スペック本製品の目玉は、40GbEに対応したことでしょうか。40GbE対応のQSFP+ポートを2つ搭載しており、ToRのスイッチとしての利用を想定していると言えそうです。また、MikroTikはこの他に、40GbE QSFP+をアップリンクとした1GbEスイッチを発表するなどしており、今後の40GbE製品の展開に期待が持てそうです。さらに、MikroTikの製品は、安いものも含めてPSUが冗長化されているのが特徴だと言えます。本製品も例にもれず、PSUは冗長化されています。購入EuroDKより、384ドルで購入しました。安い…この記事を書いている時点ではすでに売り切れとなっているようです。 外観箱はCloud Router Switchのいつもの箱です。中には簡単なマニュアル。 本体。MikroTikCloud Router Switch CRS326-24S+2Q+RMポートポートは左からSFP+ 1から24 QSFP+ 1から2 となっています。ポートの番付が下から上に1,2となっている点、間違えないように気をつけたほうがいい点ですね。背面背面にはPSUが2つ、Fanが3つ付いているようです。CRS317-1G-16S+RM も所持していますが、背面のヒートシンクがなくなった点、スリムになったように感じます。Fanはうるさい?Fanのうるささは結構気にする人が多いと思います。これについては、最新のRouterOS Stable 6.45.5 にすることで、低温時はFanは回転せず、温度が上がってくるとFanが回るようになります。個人的にはこれでかなり静かになりました。動作40GbEについては、まだ対向が届いていないので、届き次第レビューしたいと思います。本当に性能がでるの?MikroTikが公開しているブロックダイアグラムを見る感じ、L2レベルであればしっかりとワイヤースピードが出そうです。実際に、CRS317-1G-16S+RMではワイヤースピードが出ています。 利用用途ラック内ではToRのスイッチとして、CRS317-1G-16S+RMが稼働中です。 2つ合わすと10GbE SFP+ Portが

自宅環境紹介

2019/08/25 23:00

top

そういえば、自宅環境の紹介をしていなかったなと思い、急遽書きました。サーバラックサーバラックの様子をどん。上からまだラッキングしてないサーバがは横に転がってます。ちなみにLANケーブルは半分ぐらい自作です。 ストレージネットワークは10GbEで構成。ネットワーク構成はこんな感じ。知り合いとVPNを張っていて、その経路交換をBGPで行っています。スペックコアになってるProxmoxサーバのスペックはサービスホストしているものを軽く紹介。監視環境とかサービスの死活監視をZabbixにて行い、リソースの可視化をGrafanaで行っています。個人でそこまでする必要があるのかは分かりませんけどね。まとめ何も知らないところ、サブネットマスクもわからないところから約1年、個人でここまでできたのは我ながら驚いています。やはり、自分が好きに触れる物理環境があれば、何でもまず”試してみる”ことができるので良いですね。その過程で色々なノウハウも得ることができました。

top

突然ですがサーバが燃えました。中央付近、メモリのVRM回路と思われる部分が焼損していることがおわかりいただけると思います。状況とある日の夜22時ごろ、突然室内の音が変わった気がして、サーバを確認すると、うち1台が停止しており、FaultのLEDが点灯しておりました。HPのサーバでしたので、iLO4からログを確認すると、電源系のエラーが出ておりました。(スクショ忘れた)PSU以上かと思った主は、PSU#1が接続された状態でPSU#2を接続してからPSU#1を交換するという方法を取り、サーバの電源を喪失することなくPSUの交換を行いました。しかしながら、電源ボタンを押しても電源が入ることはなく、電源ケーブルを接続し直すことにしました。電源ケーブルの再接続を終え、電源ボタンを押すと…燃えたはい、燃えました。といっても目視で確認できていないですが、花火に火をつけたような音やスパークの飛ぶ音が1.5秒ほど続き、一瞬にして室内には半導体の燃える匂いでいっぱいに。ヒートシンクがマザーボードを外さずに撤去することができなかったので直視できていませんが、半導体チップが溶けてぐちゃぐちゃになっていました。チップ、半田ゴテとか当てても溶けませんから、相当の温度になっていたのでしょう。原因は?完全な原因究明には至っておりません。考えられることとしては、前日に行ったUPSのマウント作業の際、レールのかみ合わせが悪く、スライドさせるたびにカンナで削ったような金属片が散乱してしまっていましたので、それを運悪くサーバが吸い込んでショートした、ということぐらいでしょうか。 そして、ショートを検知して電源が落ちたものの、主が一度電源を喪失させたためにエラーのステートが消え、エラーをディテクトする前にサーバの電源が入ってしまって燃えた、というところでしょうか。だとすると、勝手に燃えることは無いはずです。おそらく、燃える前に止まるでしょうから。被害?まず、このサーバ、コアサーバだったのですが当然死亡しました。(というか燃えてから電源入れてない)稼働1ヶ月ほどでしたので、かなりダメージが大きいものです。あと、燃えたVRM回路から電源供給を受けていたと思われるメモリが死亡しておりました。これは廃棄。 まとめ?5万ちょっとぐらいの被害は出ましたが、家が燃えなくてよかったです。自宅でサーバ類を運用している方、

top

計測環境計測結果HDDとは思えない速度が出ているようです。おそらくストレージサーバ側でメモリキャッシュがきいているからですかね。

top

 Interop Tokyo 2019 に行ってきましたので、軽くレポートとしてまとめます。技術的な内容は一切無いのであしからず。Interop TokyoとはInterop Tokyo(インターロプ・とうきょう)とは、首都圏における、ネットワーク・インフラストラクチャー技術、製品、またそれらを用いたソリューションサービスについての展示会である。wikiよりまぁあれです。最新のネットワーク機器等が展示される展示会です。実際に機器を間近で見ることができます。 後は、ShowNetなどで行われている相互接続テストの様子や、ラックに入れられた機器が見どころの一つではあると思います。行くことになったきっかけ今回のInterop Tokyo 2019 への参加は、普段からお世話になっている教員からの提案によるものです。技術系の展示会などはどうしても関東圏での開催が多く、関西圏の学生が参加することはどうしても難しいのが実情でした。そんな中、サイオステクノロジー株式会社さんは、特に地方の技術系大学生に対して都市圏でのイベント参加を支援するプロジェクトを始めておられ、教員からの推薦もあって今回、交通費と宿泊費を支援していただけることになりました。 気になる人は支援プログラムのページをご覧ください。1日目昔、東京に住んでおりましたので、多少の土地勘はある状態で東京へ向かいました。あまりInterop自体に関係のないことも書いておりますが、久々の東京でしたので地方学生の戯言だと思って見ていただけると幸いです。東海道新幹線・京都駅構内で見つけたYAMAHAさんの広告です。YAMAHAさんの広告は初めてみましたので、思わず撮ってしまいました。せっかくですので、品川駅にて下車しサイオスさんの中の人に食事へ連れて行ってもらいました。その中で、今自身が取り組んでいることについてや、最近の学生の動向、後は雑談で、1時間ほどお話をさせていただきました。もちろん、就活とかは全く関係ありませんので、気軽にお話をさせていただくことができました。その後は、知り合いと会ったり、プチ東京観光を満喫しました。幕張へ山手線で東京駅へと向かい、京葉線へ。東京駅から京葉線ホームへの距離が長くて焦りました。 京葉線へ乗車し、快速で30分程で海浜幕張駅へと。1日目は、海浜幕張駅付近のホテルへ滞在し、翌13日にInte

top

環境ProxmoxNetwork症状ProxmoxからFreeNASへNFSで接続し、Windowsを入れる。このとき、Proxmox側のディスクドライブはIDE0この状態でCrystalDiskMarkをかけた結果が以下HDDはWD REDだし、RAID-Zとはいえ、Read/Writeともにほぼ同じ速度で頭打ちなのはおかしい。FreeNAS側でも、CPUやメモリが張り付く様子もなく、他のNFSで同じように測定されている方の結果からも、FreeNAS側の問題ではないと判断。作業結論から言うと、Proxmox上のWindowsのディスクを、IDE0からSCSI0にした。この辺は、VirtIOのドライバを入れたりしないといけないので、別途作業が必要。これがちょっと面倒である。 結果Proxmox上のWindowsのディスクをSCSI0にして、再度CrystalDiskMarkで計測した結果が以下である。 めちゃめちゃ早くなった。Readに関しては、CrystalDiskMarkの性質上、テスト前に書き込んだテスト用データがFreeNASのNFSボリューム上のキャッシュにあり、キャッシュから読み出したものだと思われる。しかしながら、Writeに関しては、ディスクから直接読み込んでいると思われる数値が出ている。結果として大幅な速度向上に成功した。 余談これはあくまでも推察なので、事実と異なるかもしれないが、CrystalDiskMarkがディスクのベンチマークを行う際、以下の順序で実行されているように思う。この手順だと、テストデータを2回書き込む必要があると考えられる。以下の処理順序にすれば、効率よくベンチマークが行えないだろうか? この順序だと、書き込みや読み込み処理が1度で済むと考えられる。当然、何か理由があって、現状の処理順序になっていると考えられるが、それが自身には分からないので、誰かご教示願いたい。

About

インフラエンジニア
主に作業ログ

About Me

Archives