投稿

2月, 2022の投稿を表示しています

QNAPのNASのTS-453Dに2つ目のHDDを追加し、RAID1を組む

イメージ
概要 複数の計算機からアクセスできるファイル保管場所としてQNAPのNASである TS-453D を導入しているが、そのNASの中身はHDDを1枚使用している状態で障害に弱い状態であった。そこでHDDをもう1枚追加しRAID1を組むことによって障害に強くする。   経緯  2022年の1月初旬に複数の計算機からアクセスできるファイル保管場所としてQNAPのNASであるTS-453Dを導入したが、同年2月下旬現在このNASはHDDを1枚のみを利用しており、このHDDに不具合が生じると保存しているデータが利用できなくなる状態にあった。そこでHDDを1枚追加しRAID1を組むことによって、1つのHDDに不具合が生じてもデータの利用がすぐにできなくなるという状態を防ぐ。   購入したもの 東芝 MN08ADA800 選定基準は1枚目に買ったHDD、 WESTERN DIGITAL Blue WD80EAZZ と同じく8TBでCMRであるHDDから選び 東芝 MN08ADA800 になった。前回買ったWESTERN DIGITAL Blue WD80EAZZとモデルが異なる理由はRAID1を組む際に同じモデルのHDDを利用すると片方に障害が生じた場合に同時にもう一方にも障害が生じる確率が高いと考えられるからである。   作業  新しく追加したHDDが利用されるまでの行った作業を示す。 取り付け HDDをNASのHDD用のトレイに嵌め込み、NASに差し込む。この時NASは稼働したままでも問題ない。   図1 NASから取り出したHDDを取り付けるトレイにHDDを嵌め込んだ   図2 稼働しているNASにHDDを差し込む 図3 NASにHDDを差し込んだ 図4 NASに蓋をして元の状態に戻す 取り付けたHDDと既存のHDDをRAID1にする設定 HDDを取り付けた後にNASにhttpで接続をすると、図2の画面でディスク2に差し込んだHDDが認識されているのが確認できる。この画面のストレージ -> ストレージ/スナップショット からディスクを追加したいストレージプールを選択し、管理を選ぶと図6の画面になる。ここで管理を選択し、RAIDグループを移行を選択すると図7の画面が表示されるので、追加するディスクを選択し、適応を押すとRAID1の構築が始まる。図8の画面でRAIDの構築

QNAPのTS-453Dを買った話

イメージ
概要 複数のコンピュータを扱っているとそれぞれのコンピュータからアクセスできるストレージが欲しくなる。今回はQNAPの TS-453D をNASとして導入することによってこの課題を解決する。   経緯 現在我が家の使用されている計算機の台数は、 スマートフォンが1台、タブレットが2台、PCが6台と、複数存在している。その端末それぞれに異なった役割があるが、利用するデータも全く異なっているという訳ではなく、音楽データなどは異なった端末でも同じデータを利用される場合がある。このとき、それぞれの端末に対して同じデータを記録させる方法もあるが、十分なデータ記憶容量を持っていない端末が存在している上に、データに変更追加削除が生じたときに全ての端末にそれを反映する作業が手間となる。すると次の方法としては、ネットワーク上にどの端末からも利用できるストレージを用意し、そこにアクセスしてもらうという方法が考えられる。   このとき、Google Driveなどのクラウドストレージサービスを利用することによって解決する方法も考えられるが、一般的にクラウドストレージサービスはアップロードされるファイルの中身を見ており、社会的に問題があると考えられるファイルがアップロードされた際に、ファイルを削除する、ストレージへのアクセスを停止させる、アカウントを停止・削除させるなどの 対 応 が取られる。ここでの問題が、どのような基準で持ってどのような手法で?というものである。個人的にミスの存在しない完璧な判定を下す機械学習・AIはないと考えており(SNSなどに投稿された何でもない画像がポルノ画像と誤判定される話などは有名だろうか?)、その誤検知に引っかかってアップロードしてきた全てのデータを消されては困るので、クラウドストレージサービス単体の利用は避ける。さらに、インターネット回線の都合やその他制約から、バックアップ用途以外は避ける。     現在、我が家のネットワーク上に存在する機器は上の図ような構成になっている。実はここにはすでに Ubuntu Server 上で Samba を使ってファイルサーバ機能を提供しているコンピュータが存在している。このコンピュータの構成は MQ04ABB400 という東芝製2.5 inch HDDが乗った ASRock Beebox J3160 となっているが、この

Poetryを使ったPythonプロジェクトをGitHub Actionsを用いてAWS Lambdaへのデプロイする仕組みについて考える

概要 GitHubで管理しているPythonプロジェクトについて、AWS Lambda上で動作させたい時に、mainブランチへのpush等、リポジトリへの特定のアクションをトリガーに自動でAWS Lambdaに自動でデプロイされるという安全で楽な仕組みが欲しくなる。 このような場合、GitHubが提供しているCI/CDプラットフォームであるGitHub Actionsを用いた自動デプロイの仕組みを作るのが手段の1つとなるが、 AWS Lambda上でPythonで記述されたコードを実行させるには、使用するパッケージを含めたファイル群をzipで固めたものをデプロイすることになる。 このとき、対象のPythonプロジェクトがPoetryを使用してパッケージの管理を行われていた場合に、GitHub Actionsを動かすyamlファイルをどのように記述するのかについて検討を行った。 結論 分かる人はGitHub Actionsの動作について記述したyamlファイルを読んだ方が早いと思うので、先にファイルの中身を見せ、この後に解説を載せる。 .github/workflows/deploy.yml name: Lambda Deploy on: push: branches: - main jobs: lambda-deploy: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v2 - name: Setup Python uses: actions/setup-python@v2 with: python-version: '3.x.x' - name: Install Poetry run: | curl -sSL https://raw.githubusercontent.com/python-poetry/poetry/master/get-poetry.py | python - echo "$HOME