cloud.google.com 何の話かというと 先日、Google Cloud MLがベータ公開されました。超ざっくりまとめると、GCPのクラウド上で次のことができるようになります。 (1) TensorFlowのコードを実行して学習済みモデルを作成する (2) 学習済みモデルをAPIサービスとして公開する（現在はアルファ版） (1)については、ハイパーパラメーターの自動チューニングや分散学習処理なども利用できるのですが、ここでは、単純に、既存のTensorFlowのコードをCloud MLに載せるための最低限の手順を説明します。 例として、下記のサンプルコードを使用します。全結合層のみの単層ニューラルネットワークでMNISTデータセットを分類する簡単な例です。 ・MNIST single layer network.ipynb ローカルで実行する場合からの修正点 まず、コードの実行に

TensorFlowを使って、実際にコードを動かしながら、DeepLearningの仕組みを段階的に学んでいきましょう。 目次 ・No.1 TensorFlow Tutorialの数学的背景 − MNIST For ML Beginners（その1） 平面上の2種類のデータをロジスティック回帰で直線的に分類するという、機械学習の基礎を説明します。 ・No.2 TensorFlow Tutorialの数学的背景 − MNIST For ML Beginners（その2） 線形多項分類器とソフトマックス関数で、3種類以上のデータを分類する方法を説明します。 ・No.3 TensorFlow Tutorialの数学的背景 − TensorFlow Mechanics 101（その1） No.1で説明した問題に対して、もっとも単純なニューラルネットワークを適用して、複雑な境界を持つ分類を実現します

RHEL7でRed Hat公式のDockerとRHEL6イメージを使用する手順です。 RHELのサブスクリプションが必要ですので、ご注意ください。 Dockerのインストール RHEL7を最小構成でインストール サブスクリプション登録 # subscription-manager register --username=<username> --password=<password> # subscription-manager list --available # subscription-manager attach --pool=<pool_id>パッケージアップデートとfirewalldからiptablesへの切り替え（iptablesへの切り替えは必須ではないですが・・・） # yum -y update # yum -y install iptables-services #

OpenStackで、仮想マシンインスタンスが稼働するCompute Nodeが障害停止した際に、仮想マシンインスタンスを復旧する方法／考え方について整理しておきます。（ハイパーバイザーはLinux KVMの前提です。） 仮想ディスクの構成について まず、前提として、仮想ディスクの構成を理解しておきましょう。ゲストOSが導入された起動ディスクについては、仮想マシンインスタンスを起動する際に、「エフェメラルディスク」、もしくは、「ブロックボリューム」のどちらかが選択可能です。 エフェメラルディスクは、Compute Nodeのローカルディスクに仮想ディスクイメージが配置されるため、Compute Nodeが障害停止するとアクセス不能になります。他のCompute Nodeで再利用することはできません。 ブロックボリュームは、Cinderが提供するディスク領域で、一般的には、外部のストレージ装

journaldとは？ systemdの環境で、標準的に提供されるログ管理のサービスです。正式名称は、下記の「systemd-journald.service」です。 # systemctl status systemd-journald.service systemd-journald.service - Journal Service Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static) Active: active (running) since 月 2014-11-24 16:27:08 JST; 5 days ago Docs: man:systemd-journald.service(8) man:journald.conf(5) Main PID: 334 (systemd-jour

参考資料 ・Predictable Network Interface Names 何の話かというと RHEL7では、NICのネーミングルールが変わっています。RHEL6では、DELL製のハードウェアの場合だけネーミングルールが変わるという謎のudevルール（biosdevname）がありましたが、RHEL7では、さらにまた仕組みが変わって、systemdがNICのネーミングを行うようになりました。 まとめると次のようになります。 バージョン ハードウェア ネーミングルール RHEL5 すべて 古典的な「eth0」「eth1」など RHEL6 一般のマシン 古典的な「eth0」「eth1」など RHEL6 DELL製のハードウェア biosdevnameによる「em1」「em2」「p1p1」など RHEL7 一般のマシン Predictable Network Interface Name