inode使用率をcloudwatchになげるスクリプト(mon-put-data)
■inodeをcloudwatchに出力するスクリプト
環境変数、アクセスキーとかは適宜変更が必要
■スクリプト例
#!/bin/bash
##############################################
# スクリプト名 : inode_cloudwatch.sh
# 機能概要 : inodeデータをcloudwatchに出力
# 実行ユーザ : root
# 特記事項 :
##############################################
# 変数設定
##############################################
export JAVA_HOME=○○
export EC2_REGION=ap-northeast-1
export AWS_CLOUDWATCH_HOME=/○○/○○
export PATH=$PATH:$AWS_CLOUDWATCH_HOME/bin
export AWS_CREDENTIAL_FILE=/○○/○○/○○/.keyfile/aws.properties
InstanceId=`wget -q -O - http://169.254.169.254/latest/meta-data/instance-id`
# inode check
inodeUtilzation=`df -i | awk 'NR==2' | awk '{print $5}' | sed -e 's/%//g'`
mon-put-data --metric-name "inodeUtilization" --namespace "Custom Metrix" --dimensions "InstanceId=$InstanceId" --value "$inodeUtilzation" --unit "Percent"
XAResouce勉強メモ
https://access.redhat.com/solutions/18182
■問題
Could not find new XAResource to use for recovering non-serializable XAResourceがログに出る。
■原因
XA transactionがコミットと準備の間で落ちてる。
トランザクションリカバリマネージャは、この疑いのあるトランザクションを解決しようとするけど、
適切なXAResourceがみつからず、そのためログに出てるよ。
■解決
XA resourceのリカバリ設定をする。
https://access.redhat.com/solutions/27402
■問題
ロールバックとトランザクションリカバリはどう関係しているのか?
■解決策
通常のロールバックとJBossTSのトランザクションリカバリマネージャが実施するやつを混同するな。
ロールバックはいろんな理由で起きる。トランザクションリカバリは、ロールバックに巻き込まれないから。
JossTSのトランザクションリカバリマネージャはXA transactionsで処理するよ。全てのリソースが準備されているやつ、かつ
コミットのフェーズで不幸にも落ちた何かを処理するよ。
https://access.redhat.com/solutions/60858
■問題
<xa-datasource>の設定について、
どうやってJDBCがトランザクションリカバリの無効化できる?
■解決策
In XA datasourceの設定
設定ファイル deploy/*-ds.xml
設定項目<xa-datasource>
<no-recover>true</no-recover>
注意:
TxConnectionManager service configuration <tx-connection-factory>
の場合、トランザクションリカバリ無効化はできない。
https://access.redhat.com/articles/216083
ディザスタリカバリ設定について
割愛
勉強メモ01
本日の勉強メモ。
■CNAMEレコードとAレコードの違い
CNAMEは、特定のホスト(FQDN)を別のホスト(FQDN)に転送する時のレコード
Aレコードは、ホスト(FQDN)とサーバーを識別するグローバルIPアドレスの関連づけを定義するレコード。
ELB は、CNAME しか登録できない。なぜか。↓
ドメイン名を使ってEC2を運用していたら、ELBのスケールアウトで苦労した話 - MUGENUP技術ブログ
SSHの仕組み!ぼんやりとした理解だったものをすっきりさせようの会 - nigoblog
Amazon VPCのネットワークACLについて | Developers.IO
■SSLの仕組み
図解で学ぶネットワークの基礎:SSL編 - 図解で学ぶネットワークの基礎:SSL編:ITpro
公開鍵と秘密鍵をわかりやすく教えてください。使い方、発信者が秘密鍵... - Yahoo!知恵袋
◇SSL通信の機能
①データの暗号化
②サーバの認証
◇SSLの位置
アプリ→SSL→TCP→IP→物理→IP→TCP→SSL→アプリ
◇共通鍵方式と公開鍵方式
◇認証
①CA
証明内容をハッシュ
ハッシュした値をCAの秘密鍵(署名鍵)で暗号化し、署名とする
②クライアント
証明内容をハッシュ
署名をCAの公開鍵(検証鍵)で復号し、ハッシュ値が同じか確認
Pre-Warming についてメモ
Best Practices in Evaluating Elastic Load Balancing : Articles & Tutorials : Amazon Web Services
Best Practices in Evaluating Elastic Load Balancing : Articles & Tutorials : Amazon Web Services
Pre-Warming the Load Balancer
Amazon ELB is able to handle the vast majority of use cases for our customers without requiring "pre-warming" (configuring the load balancer to have the appropriate level of capacity based on expected traffic). In certain scenarios, such as when flash traffic is expected, or in the case where a load test cannot be configured to gradually increase traffic, we recommend that you contact us to have your load balancer "pre-warmed". We will then configure the load balancer to have the appropriate level of capacity based on the traffic that you expect. We will need to know the start and end dates of your tests or expected flash traffic, the expected request rate per second and the total size of the typical request/response that you will be testing.
構築メモ
構築メモ
Fluentd を使って CloudWatch のメトリクスを Graphite で見れるようにする - Qiita
td-agentとFluentdの違い - tsunokawaのはてなダイアリー
td-agentはFluentdの安定版,Fluentdはルビー環境、gemとかいる。。
rpmパッケージからFluentdをインストールする | Fluentd
RDSシステムアップグレードに関するAWSからの案内の翻訳2
Dear Amazon RDS Customer,
RDSご利用の皆様へ
As you are aware, Amazon RDS underwent a maintenance event between 26 September 2014 and 30 September 2014 to protect your instances from any security risks associated with the now public Xen Security Advisory XSA-108 (detailed on the AWS Blog:http://aws.amazon.com/blogs/aws/ec2-maintenance-update-2).
お気づきのように、2014年9月26日から30日にpublic Xen Security Advisory XSA-108脆弱性に関連して安全性を高めるためのRDSについてメンテナンスを実施しました。
Prior to this maintenance, Amazon RDS had also announced an independent, mandatory upgrade that would require offline patching, within the window of 8 October 2014 to 28 October 2014, that would affect all MySQL and PostgreSQL instances created before 02 October 2014 00:00:01 UTC.
このメンテナスより先に、オフラインのパッチのために2014年10月2日以前に作成された全てのMySQLと PostgreSQLのDBインスタンスを対象にした、2014年10月8日から28日の強制的なアップグレードを独立してアナウンスしていました。
However, the unplanned XSA-108 maintenance forced us to delay progress on this planned maintenance. We also received feedback that having two maintenance events scheduled so close to each other was overly disruptive and that RDS customers want more control over when to install updates and experience maintenance outages.
しかし、想定していない XSA-108メンテナンスのために、我々はこの計画していたメンテナンスを遅らせる必要が出てきました。我々はこの二つのメンテナンスがあまりに破壊的なくらい近すぎるというフィードバックをもらっています。そして、RDS利用者はメンテナス時間(停電)の実施やアップデートのインストールをもっとコントロールしたいというフィードバックももらっています。
As a result of these factors, we are pushing back our dates for the mandatory RDS maintenance, and are also looking into ways to make RDS instance maintenance more controllable by you.
これらのファクターの結果、我々は強制的なRDSメンテナンスの日付を延期することにしました。またメンテナスをもっと利用者がコントロールできるように変更します。
The mandatory maintenance will now be carried out during the first quarter of 2015.
この強制的なメンテナンスは現在、2015年の初めての四半期で実施予定です。
As before, maintenance will happen during your preferred maintenance window and we will send an email containing more details about your scheduled maintenance at least one month prior to the start of maintenance.
その前に、今度のメンテナンスは、あなたがメンテナンスウィンドウで臨んだ時間にメンテナンスをするようになるでしょう。そして最低でもメンテナンス期間の開始の1か月以上前にメールを送ります。
The email will include detailed maintenance windows for each region, as well as the date after which new instances will have updates applied (that is, all instances created before that date would have to undergo the upgrades).
そのメールは各リージョンのメンテナンスウィンドウの詳細を含んでます。
メンテナンスウィンドウはアップデートを受けるはずの新しいインスタンスも同様に含んでいます(アップグレードを受けるはずの時期(??2014年10月2日??)より前に作成されたすべてのインスタンスが対象だよ。)
In addition, the email will contain information about how you can schedule the update at a time of your choosing if the time chosen by RDS isn’t optimal for you.
加えて、そのメールは、もしも指定されたRDSメンテナンスの時間が好ましくない場合にどのようにアップデートの時間を選ぶかなど情報も含んでいます。
Should you have any questions or concerns, the AWS Support Team is available on the community forums and via AWS Support.
もしももっと質問や心配があればサポートかフォーラムに質問するとよいよ
Sincerely,
Amazon Web Services
RDSシステムアップグレードに関するAWSからの案内の翻訳
Dear Amazon RDS Customer,
Amazon RDS ご利用の皆様へ
All Amazon RDS for MySQL and PostgreSQL database instances have been scheduled to receive mandatory system upgrade as per the schedule below during the maintenance window you defined for them. For example, if you have chosen Thursday 16:00 UTC with a duration of 30min as the maintenance window for your database instance in the US West (N. California) Region, it will receive the system upgrade on 16 October 2014 (Thursday) between 16:00 UTC and 16:30 UTC.
全てのMySQL と PostgreSQL用のRDS DBインスタンスは、強制的なシステムアップグレードが計画されています。それらのスケジュールはメンテナンスウィンドウでそれぞれ時期を特定できます。例えば、もしも、あなたがUS West リージョンのDBインスタンスについて木曜日の16:00UTCからの30分間をメンテナンスウィンドウで選んだ場合、システムアップグレードが2014年10月16日の16:00UTCから16:30になります。
Please note that while the upgrade completes, your DB Instance will have an availability impact for a few minutes during your maintenance window (even if you chose “No” for the “Auto Minor Version Upgrade” option). Therefore, please cross check your maintenance window settings to ensure that they are set as per your needs using the schedule above.
アップグレードが完了するまでの間、注意してください。あなたのDBインスタンスはメンテナンスとなっている数分間の可用性へ影響があります。(たとえ、オートマイナーバージョンアップオプションをNoを選んでいたとしても)
For Multi-AZ deployments, upgrade first occurs on your standby node, followed by a failover, limiting your availability impact to typically 60 - 120 seconds. You can subscribe to Event Notifications ( http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_Events.html ) for the “Maintenance” Category to receive notifications when your instance gets upgraded.
Multi-AZ構成の対象は、アップグレードははじめスタンドバイ側DBノード()で起こり、続いてアクティブ側DBノードでシステムアップグレードが起こりフェールオーバーが起こり、通常であれば60秒から120秒使えなくなる、(可用性への制限がかかる)。あなたはシステムアップグレードが起き、メンテナンスカテゴリとなった場合のイベント通知を受けることができます。
Note that this maintenance schedule is only applicable for MySQL and PostgreSQL database instances. Also, any MySQL or PostgreSQL database instance created after 29 Sep 2014 00:00 UTC will already have this upgrade and will not be impacted by this maintenance.
注意:このメンテナンスのスケジュールは、MySQL と PostgreSQL のDBインスタンスのみ適応される。さらに、2014年9月29日00:00UTCより後に作られたMySQL と PostgreSQL のDBインスタンスは既にこのアップグレードされているため、このメンテナンスの対象外です。
Lastly, if you are using MySQL 5.6, you may want to evaluate turning on InnoDB Cache Warming ( http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_MySQL.html#MySQL.Concepts.InnoDBCacheWarming) and dumping the buffer pool before the upgrade to improve read latency after your instance restarts.
最後に、もしもMySQL5.6だった場合、あなたはInnoDB Cache Warming に変更されることの評価が必要になるやも。アップグレード前のバッファプールをダンプして、インスタンスがアップグレード後再起動して読み込み遅延が改善したかを。
Should you have any questions or concerns, the AWS Support Team is available on the community forums and via AWS Support Portal.
質問や心配があるなら下記に質問した方がいいよ
https://forums.aws.amazon.com/forum.jspa?forumID=60
Asia Pacific (Sydney)
+++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 8 Oct 2014 22:00 UTC Maintenance Schedule End Date: 15 Oct 2014 21:59 UTC
Asia Pacific (Singapore)
++++++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 13 Oct 2014 00:00 UTC Maintenance Schedule End Date: 19 Oct 2014 23:59 UTC
South America (São Paulo)
++++++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 13 Oct 2014 11:00 UTC Maintenance Schedule End Date: 20 Oct 2014 10:59 UTC
US West (N. California)
++++++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 13 Oct 2014 15:00 UTC Maintenance Schedule End Date: 20 Oct 2014 14:59 UTC
US West (Oregon)
++++++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 15 Oct 2014 15:00 UTC Maintenance Schedule End Date: 22 Oct 2014 14:59 UTC
Asia Pacific (Tokyo) Region
++++++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 15 Oct 2014 23:00 UTC Maintenance Schedule End Date: 22 Oct 2014 22:59 UTC
EU (Ireland)
++++++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 16 Oct 2014 07:00 UTC Maintenance Schedule End Date: 23 Oct 2014 06:59 UTC
US East (N. Virginia): MySQL 5.1/5.5
+++++++++++++++++++++++++++++++++++++
Engine/Version Affected: MySQL 5.1/5.5
Maintenance Schedule Start Date: 16 Oct 2014 12:00 UTC Maintenance Schedule End Date: 23 Oct 2014 11:59 UTC
US East (N. Virginia): MySQL 5.6/PostgreSQL
+++++++++++++++++++++++++++++++++++++
Engine/Version Affected: MySQL 5.6/PostgreSQL Maintenance Schedule Start Date: 21 Oct 2014 12:00 UTC Maintenance Schedule End Date: 28 Oct 2014 11:59 UTC
China (Beijing)
++++++++++++++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 21 Oct 2014 00:00 UTC Maintenance Schedule End Date: 27 Oct 2014 23:59 UTC
GovCloud (US)
+++++++++++++
Engine/Version Affected: All MySQL/PostgreSQL Maintenance Schedule Start Date: 21 Oct 2014 15:00 UTC Maintenance Schedule End Date: 28 Oct 2014 14:59 UTC
Sincerely,
Amazon Web Services