2020年7月21日火曜日

仮想マシンの停止時や起動時のLog Analytics Agentの動作について

Log Analytics AgentはOSのログ情報やメトリック情報を Azure Monitor の Log Analytics ワークスペースに送信するものですが、仮想マシンの停止時や起動時 (=OSの停止時や起動時) にどのような動作をするのか調べてみました。 ここでは、対象は仮想マシン、OSはCentOS 7.5、Syslogの送信、とします。また、SyslogのINFOログを送信するように設定済みであるとします。

調査方法:
  1. SyslogにINFOログを10秒ごとに送信するスクリプトを実行する。
  2. ここでは、以下のスクリプトを実行します。
    $ while true; do currentdate=$(date); logger -p user.info message for info on $currentdate; sleep 10s; done
    
  3. Log AnalyticsワークスペースにINFOログが送信されることを確認したら、SyslogにINFOログが送信された直後に仮想マシンを停止する。
  4. 5分ほど停止させ、Log Analyticsワークスペースにログが送信されてこないことを確認したのちに、仮想マシンを起動する。
結果:
  • 仮想マシン停止時には、直前にSyslogに送信されたログがLog Analyticsワークスペースに送信されませんでした。
  • 仮想マシンを起動すると、仮想マシン停止の直前にSyslogに送信したログがLog Analyticsワークスペースに送信されました。
Agentはどこまでのログを送信したかという情報をバッファに持つのですが、AgentはLog Analyticsワークスペースに定期的にログを送信するのみで、仮想マシン停止時にバッファを見てログを送信するという動作はしていないことになります。なお、Agentがログを送信するタイミングは/etc/opt/microsoft/omsagent/conf/omsagent.confに記述されており、CentOS 7.5の場合はバッファのフラッシュが10s毎、リトライ回数6回、リトライインターバル30sになっています。

なお、ドキュメントには
エージェントが Azure Monitor または Operations Manager に接続できない場合は、そのままデータの収集を続け、接続が確立されたときにデータを送信します。 データの量がクライアントの最大キャッシュ サイズに達した場合、またはエージェントが 24 時間以内に接続を確立できなかった場合は、データが失われることがあります。
という記述があるので(https://docs.microsoft.com/ja-jp/azure/azure-monitor/platform/agent-data-sources#data-collection) 、調査方法の手順3での停止時間を24時間以上にしてテストしてみましたが、仮想マシン起動後に未送信のログがLog Analyticsワークスペースに送信されました。起動状態で24時間なのかどうかは今後要調査です。

2020年5月29日金曜日

Azure Data Factoryでzipファイルを展開して格納する方法について

Azure Data Factory (ADF) で、zipファイルを展開して格納する方法について記述します。
ADFのコピーアクティビティにはzipファイルを展開してくれる機能がありますが、いくつか注意点があります。
  • zipファイルはバイナリファイル、展開されたファイルはフラットファイル (Json、CSV等) になるので、コピーアクティビティの入力フォーマットは「Binary」、出力フォーマットは「Json、DelimitedText等」になると思われますが、コピーアクティビティでは入力フォーマットが「Binary」の場合は、出力フォーマットも「Binary」として定義する必要があります。
  • ワイルドカードでファイル指定をする場合は、データセットでファイルを指定せず、コピーアクティビティの設定でファイルを指定します。
  • コピーアクティビティにはファイル処理の中でエラー行をスキップする機能があるのですが、zipファイルが破損している場合、破損ファイルをスキップすることができません。つまり、複数のzipファイルをコピーアクティビティで処理させる場合には、事前にzipファイルの破損の有無をチェックしておく必要があります。
設定例を以下に記載します。こちらの例では、Azure Data Lake Storage Gen2のフォルダに複数のzipファイルが格納されており、これを抽出して展開、別のフォルダに展開されたファイルを格納するという処理を行います。
  1. 入力用のデータセットの設定
    • フォーマットを「Binary」としてデータセットを作成
    • File pathには、zipファイルが格納されているフォルダ (例:filesystem1/folder1) まで指定
    • Compression typeには、「ZipDeflate」を指定
  2. 出力用のデータセットの設定
    • フォーマットを「Binary」としてデータセットを作成
    • File pathには、展開されたファイルを格納するフォルダ (例:filesystem1/folder2) を指定
    • Compression typeには、「none」を指定
  3. コピーアクティビティのソースの設定
    • Source datasetには、1で作成したデータセットを指定
    • File path typeには、「Wildcard file path」を指定
    • Wildcard pathには、ファイル名 (例:filesystem1/folder1/*.zip) まで指定
  4. コピーアクティビティのシンクの設定
    • Sink datasetには、2で作成したデータセットを指定
    • Copy behaviorには、zipファイル内部の構造やファイル名を維持する場合は「Preserve hierarchy」、維持せずフラットな構造にする場合は「Flatten hierarchy」を指定 
      • 「Preserve hierarchy」を指定した場合は、zipファイル名のフォルダが作成され、その配下にzipファイルが展開されます
      • 「Flatten hierarchy」を指定した場合は、指定されたフォルダの直下に全てのzipファイルが展開されますが、ファイル名は勝手に生成されます


2020年4月27日月曜日

Synapse Analyticsのメンテナンススケジュールの注意点

Synapse AnalyticsのSQLプールでは、ユーザー指定でのメンテナンススケジュールが設定できるようになっています。
https://docs.microsoft.com/ja-jp/azure/synapse-analytics/sql-data-warehouse/maintenance-scheduling/

ただし、DWUが400c以下の場合には、占有リソースにならないこともあり、指定したメンテナンススケジュール通りにはならないことがあります。これは上記のドキュメントにも記載されています。

なお、DWUが400c以下の場合にはメンテナンススケジュールが設定できなくなっているため、どうしても設定したい場合には一度DWUを500c以上に上げてメンテナンススケジュールを設定したのち、DWUを400c以下に変更してください。

繰り返しになりますが、この場合はメンテナンススケジュール通りにメンテナンスされる保証はありません。

2020年4月14日火曜日

Ubuntu 18.04LTSにMinikubeをインストールする手順

様々なパブリッククラウドでKubernetesのマネージドサービスが出てきており、すぐにKubernetesを使える環境が得られるようになっていますが、一から作った環境で調査するのも有用な場合があります。ここでは、1台のPC上に仮想的にKubernetesの環境を構築できるMinikubeの環境構築手順を記述します。なお、OSはUbuntu 18.04LTS、ハイパーバイザーとしてはKVMを使います。

Visualizationのチェック:
以下のコマンドを実行します。何かしら出力されればOKです。
$ grep -E --color 'vmx|svm' /proc/cpuinfo


kubectlのインストール:
$ sudo apt-get update && sudo apt-get install -y apt-transport-https
$ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
$ echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee -a /etc/apt/sources.list.d/kubernetes.list
$ sudo apt-get update
$ sudo apt-get install -y kubectl


Hypervisor(KVM)のインストール:
$ sudo apt install libvirt-clients libvirt-daemon-system qemu-kvm


KVM2ドライバーのインストール:
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/docker-machine-driver-kvm2 && sudo install docker-machine-driver-kvm2 /usr/local/bin/


Minikubeのインストール:
$ curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube_1.8.1-0_amd64.deb \
 && sudo dpkg -i minikube_1.8.1-0_amd64.deb


Minikubeの起動: 一旦minikube deleteコマンドを実行したほうがよいです。
$ minikube delete
$ minikube start

2019年3月28日木曜日

C#でasync Mainメソッドを使いたいとき

C# 7.1からasync Mainメソッドが使えるようになったので、Mainメソッドから直接非同期メソッドをコールできるようになりました。

ただし、Visual Studioでデフォルトの設定だとビルドの言語バージョンが「C#の最新のメジャー バージョン (既定)」になっており、この場合C# 7.0を指している場合があります。
ビルド実行時に「エントリ ポイントに適切な静的 'Main' メソッドを含んでいません」というエラーが出る場合はこれにあたっているため、ビルドの言語バージョンで具体的なC#のバージョンを指定するか、「C#の最新のマイナー バージョン (最新)」を選択してみてください。

2019年1月22日火曜日

Bot Framework v4で、App ServiceにデプロイするとInternalServerErrorが出る現象について

Bot Framework v4でEmulatorでは通常に動作するものの、App ServiceにデプロイしてアクセスするとInternalServerErrorが出ることがあります。

こちらの現象について、4.1.5のバージョンでは以下の対処にて解決できました。

1..botファイルの修正
Visual StudioでBotアプリのプロジェクトを開くとxxx.botというファイルがありますが、こちらのservicesのエントリを以下のように記述してください。本来はApp Serviceのアプリケーション設定でアプリケーションIDやパスワードを設定するはずなのですが、これがうまく動作していないようです。
  "services": [
    {
      "type": "endpoint",
      "appId": "<アプリID>",
      "appPassword": "<パスワード>",
      "endpoint": "https://<デプロイしたApp ServiceのURL>/api/messages",
      "id": "<ボットID>",
      "name": "production"
    },
    {
      "type": "endpoint",
      "appId": "",
      "appPassword": "",
      "endpoint": "http://localhost:3978/api/messages",
      "id": "2",
      "name": "development"
    }
   ],


2. ライブラリを以下で指定(これは細かいバージョンによって異なる可能性があります)
・ターゲットフレームワーク:.NET Core 2.1
・Microsoft.Bot.xxx -> 4.1.5
・Microsoft.AspNetCore、Microsoft.AspNetCore.All -> 2.1.6

2018年9月18日火曜日

SQL Datababse Migration InstanceのIOPSの考え方

SQL ServerをAzure上に配置する場合、ディスクごとにIOPSのキャップがかかるので、データファイルを複数のディスクに分散配置させることでパフォーマンスを向上させることができます。

SQL Database Managed Instanceの場合はこれとは異なり、Premium Storageがデータファイルごとに使われるため、データファイルごとにIOPSのキャップがかかります。このため、データファイルの数やサイズの設計を考える必要があります。

Premium StorageはP10~P50が使われ、データファイルの大きさに従って動的に切り替わります。例えばデータファイルの大きさが100GBの場合はP10が使われるため、IOPSのキャップは500になります。大きさが200GBになるとP10のサイズは128GBであるためP20に切り替わり、IOPSのキャップが1100になります。
データファイルのサイズが小さくなる場合も同様の動きになります。例えば、200GBのデータファイルが100GBに縮小された場合、P20からP10に切り替わり、IOPSのキャップは500になります。

2018年8月20日月曜日

自分のPCからAzure DCへの通信速度を計測する方法

自分のPCのブラウザから、Azureの各データセンターへの通信速度が計測できます。
地方にお客様がいる場合、どこのデータセンターが近いかを確認できますね。

http://azurespeedtest.azurewebsites.net/

2018年7月25日水曜日

Azure Active DirectoryのExpressRouteサポートが変わったようです

以下、結構要注意なので備忘録を兼ねて。

ExpressRouteでPublicピアリングやMicrosoftピアリングを有効にして利用している環境では、Azure ADに対する認証トラフィックがExpressRouteを経由していました。
これが 2018 年 8 月 1 日から次のように変更されます。
Microsoftピアリング、かつExpressRouteを利用するサービスとして“その他のOffice 365 Onlineサービス (12076:5100)”のBGPコミュニティを利用するように構成されている場合のみExpressRouteを経由する。

ただし、2018/5/1現在ではサポートリクエストをあげることにより利用可能となっているようです。

詳細は以下のURLを参照してください。
https://blogs.technet.microsoft.com/jpazureid/2018/07/19/azuread-expressroute/

2018年5月1日火曜日

SQL Data WarehouseのGen2 アーキテクチャがGAになりました

従来のSQL Data Warehouseのアーキテクチャに加えてGen2と呼ばれるアーキテクチャがGAになりました。 これはメモリやディスク配置のキャッシュを使い、アクセスが多いデータを透過的にキャッシュする機構を持っています。また、同時クエリも128までに拡大されました。

ただし、2018/5/1現在ではサポートリクエストをあげることにより利用可能となっているようです。
詳細は以下のURLを参照してください。
https://azure.microsoft.com/en-us/blog/blazing-fast-data-warehousing-with-sql-data-warehouse-gen2/

2018年3月2日金曜日

pythonでdlibのインストール、インポートでエラーが発生する場合

以下、Windows環境での対応

「pip install dlib」を実行するとcmakeの実行でエラーが起きる場合は、「conda install -c menpo dlib」を実行してみる。

python実行時に「import dlib」で「ImportError: DLL load failed」エラーが発生する場合、CNTK環境の場合はzlib.dllのファイル名を変更してみる。(他への影響は検証中)


2018年2月9日金曜日

Azureで日本語化済みWindows環境をゴールデンイメージにするときの注意点

AzureでWindows Serverの仮想マシンを作成すると英語環境になるので、これを日本語化してゴールデンイメージを作成することが多いと思います。

ゴールデンイメージの作成は以下のドキュメントの手順に沿えばできるのですが、
Azure で一般化された VM の管理対象イメージを作成する

これを行う前に、コントロールパネルの「地域」から「ようこそ画面と新しいユーザーアカウント」セクションの「設定のコピー」を選択して、新しいユーザーアカウントに現ユーザーの設定をコピーしてください。これを行うことで、作成したゴールデンイメージから作成した仮想マシンのユーザーも日本語になります。

2018年1月12日金曜日

CPU脆弱性に対する各パブリッククラウドベンダーの対応

年始に騒がれたCPU脆弱性に対して、各パブリッククラウドベンダーの対応状況をまとめて頂いているサイトがあったので備忘録として。
Azure、AWS、GCP、Alibaba CloudのCPU脆弱性対応のまとめ

2018年1月5日金曜日

Azure VMからの送信通信量はMicrosoftは管理できないということ

Microsoftに限らずパブリッククラウドサービスではクラウド利用者とクラウド提供事業者の間で責任範囲を分担しています。例えばIaaSで言えばハードウエア、ホストOSまでのレイヤでは事業者に責任があり、ゲストOSより上位のレイヤは利用者に責任があるということになります。

責任分担の考え方からいうと、VM内部のOS以上のレイヤーで行っている通信内容は利用者の持ち物ということになりますので、Microsoftではデータプライバシーの観点からも原則的にVMの通信に干渉したり、通信内容や宛先を記録することは行っていません。

AzureではVMからインターネットまたは他のデータセンターに出ていく通信に対しては料金が発生しますが、上記の理由からMicrosoftではこの通信量について調査することはできません。ですが、利用者が通信量を調査できるようにする仕組みは提供していますので、これをうまく活用して通信量を把握しましょう。

詳細は以下のリンクを参照してください。
VM からの送信方向の通信量 (Data Transfer Out) について

Azure VM からのメール送信に関する動作変更について

Azureでは、Azure上のVMから直接SMTP等を使ってメール送信することはプラットフォームとしてサポートをしていません。その代わりにSMTPリレーサービスを利用することを推奨しています。詳細は以下のリンクを参照してください。
Azure 上にメールサーバー/SMTP サーバーを構築する場合の注意事項

この動作は不正なユーザーによるAzureからのスパムメールの送信やIP アドレスのレピュテーション(メールの送信元としての信頼性)を保ち、正当な利用を行っているお客様に対して影響が及ばないようにするためのものですが、この対策がさらに強化され、Azure VMから外部ドメインへの直接のメール送信は、特定の契約種別のサブスクリプションでのみ許可するよう動作が変更されました。許可されていない契約種別のサブスクリプションにおいては、Azure VMからのTCP/25 ポートによる外部へのメール送信を Azureプラットフォームがブロックする動作が加わります。ただし、これは2017年11月15日以降に作成されたサブスクリプションのみに適用されます。詳細は以下のリンクを参照してください。
Azure VM からのメール送信に関するアナウンス (2017 年 11 月)

2017年11月10日金曜日

Visual Studio CodeでSQLサーバーにSQLを発行する方法

Visual Studio CodeでSQLサーバーへ接続し、SQLを発行する手順は以下になります。
  1. mssql拡張機能をインストール
  2. 新しいファイルを作ったら、「Ctrl-K, M」で言語を選択して、「SQL」を選択
  3. 「Ctrl-Shift-C」もしくは「Ctrl-Shift-P」から「MS: Connect」を選択
  4. 作成済みのConnection Profileがあれば選択、無ければ「Create Connection Profile」を選択
  5. Connection Profileを作成する場合は、サーバー名等の接続情報を入力 (settings.jsonを直接編集するのも可)
  6. SQLサーバーに接続したら、SQLを記述し、「Ctrl-Shift-E」で実行

2017年10月10日火曜日

Azure SQL DBにVET Service TunnelまたはVNET ACLと呼ばれる機能が追加されました。
Public preview: Virtual network service endpoints for Azure Storage and SQL Database

これはSQL DBからみて特定のVNETに属しているVMからのみのアクセスを許可するというものです。アクセスはパブリックIPによる接続になります。プライベートネットワーク内にSQL DBを囲い込むものではないのですが、従来のファイアウォール規則でのIP範囲によるアクセス許可よりも柔軟にできるため、いろいろ使い勝手はあがりそうです。

2017年7月31日月曜日

Bing Web Search APIのサービスレベル変更に伴う課金について

Microsoft Cognitive Sercicesの一つであるBing Web Search APIの課金は月単位で行われます。サービスのレベルをアップグレードすると、FAQに記載されているようにアップグレード後のレベルに対応する課金レートと含まれるトランザクション数がすぐに適用されます。

ただし、月の途中でダウングレードしても、その月で最も高いサービスレベルの課金レートが適用されるとのことです。

2017年5月25日木曜日

Azure Database for MySQLを使ってみる

Azure Database for MySQLがパブリックプレビューとしてリリースされたので、こちらのドキュメントの手順に従って、サービスを作成してみます。
https://docs.microsoft.com/ja-jp/azure/mysql/

PowerShellのドキュメントが無いので、Azure CLIでMySQLサーバーを作成します。Azure Cloud ShellにCLI環境及びmysqlコマンドラインツールが入っているので、こちらを使ってもよいと思います。

Azureサブスクリプションにログインしたら、まずリソースグループ「rg-manageddb」を東日本に作成します。
az group create --name rg-manageddb --location japaneast

Azure Database for MySQLサーバーを作成します。サーバー名「mkmysql01」、管理者ユーザー「mysqladmin」、パフォーマンスレベル「Basic」、コンピューティングユニット「100」で東日本に作成します。なお、2017/5/25時点ではバージョンを指定しない場合は5.6で作成されるようです。
az mysql server create --resource-group rg-manageddb --name mkmysql01 \
  --location japaneast --admin-user mysqladmin --admin-password Password01! \
  --performance-tier Basic --compute-units 100 
※ 引数が2017/5/25時点のドキュメントと異なっているようで、管理者ユーザーのユーザー名とパスワードは「--admin-user」、「--admin-password」で指定するようです。

MySQLサーバーに接続するために、ファイアウォールを設定します。ここでは接続するクライアントのIPのみ許可しています。
az mysql server firewall-rule create --resource-group rg-manageddb \
  --server mkmysql01 --name AllowClientIP \
  --start-ip-address <クライアントのIPアドレス> \
  --end-ip-address <クライアントのIPアドレス>

以上でMySQLサーバーの作成及び初期設定が完了しました。

次に、作成されたMySQLサーバーの初期状態を確認してみます。

MySQLサーバーに接続するためのホスト情報を取得します。結果はJSON形式で取得できます。fullyQualifiedDomainNameがホスト情報になります。
az mysql server show --resource-group rg-manageddb --name mkmysql01

mysqlコマンドラインツールでMySQLサーバーに接続します。
mysql -h mkmysql01.mysql.database.azure.com -u mysqladmin@mkmysql01 -p

データベースを確認します。
mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
+--------------------+

「mysql」データベースに接続して、テーブルを確認します。
mysql> use mysql

mysql> show tables;
+---------------------------+
| Tables_in_mysql           |
+---------------------------+
| __firewall_rules__        |
| columns_priv              |
| db                        |
| event                     |
| func                      |
| general_log               |
| help_category             |
| help_keyword              |
| help_relation             |
| help_topic                |
| innodb_index_stats        |
| innodb_table_stats        |
| ndb_binlog_index          |
| plugin                    |
| proc                      |
| procs_priv                |
| proxies_priv              |
| servers                   |
| slave_master_info         |
| slave_relay_log_info      |
| slave_worker_info         |
| slow_log                  |
| tables_priv               |
| time_zone                 |
| time_zone_leap_second     |
| time_zone_name            |
| time_zone_transition      |
| time_zone_transition_type |
| user                      |
+---------------------------+

ユーザーを確認します。
mysql> select host,user from user;
+-----------+-----------------+
| host      | user            |
+-----------+-----------------+
| %         | mysqladmin      |
| 127.0.0.1 | azure_superuser |
| localhost | azure_superuser |
+-----------+-----------------+

作成後はこのような状態でした。

2017年5月11日木曜日

Azure Cloud Shell

Azure PortalでCLIが使えるAzure Cloud Shellが提供されるようになりました。なお、Java、Node、GOあたりも初めから入っています。
dmesgでみるとUbuntuを使っているようですね。