No puedo contar el número de veces que algo en TI me ha fallado. El disco duro de mi equipo portátil dejó de funcionar el día antes de una conferencia, una fuente de alimentación humeando en un servidor de correo electrónico y fallas en las interfaces de red en un router de núcleo. Y ni siquiera quiero mencionar las actualizaciones de sistema operativo, controlador y firmware. Estoy seguro de que cualquier persona que trabaje en TI le encantaría compartir historias de horror de las situaciones con las que han tenido que lidiar, especialmente las ocurridas a última hora de la noche o en un momento crucial para la empresa. ¿Sucede alguna vez algo así como un buen fracaso en un buen momento?
Si prevé fallas en TI, aprende a planificar y diseñar sus aplicaciones para que se adapten a los problemas. En este capítulo, aprenderá a utilizar funciones de alta disponibilidad y redundancia de Azure para minimizar los cortes causados por actualizaciones de mantenimiento e interrupciones. Este capítulo crea una base de conocimientos para los próximos dos o tres capítulos a medida que comienza a pasar de una aplicación que se ejecuta en una sola VM o aplicación web, a una que puede escalar y distribuirse globalmente.

La necesidad de redundancia
Si desea que los clientes puedan confiar en usted sus importantes negocios de pizza, debe suministrar aplicaciones a las que puedan acceder cuando las necesiten. La mayoría de los clientes no buscan «horas de atención» en un sitio web, especialmente si trabaja en un entorno global y los clientes están en todo el mundo. ¡Cuando tienen hambre, quieren comer!
La figura 7.1 muestra un ejemplo básico de una aplicación que se ejecuta en una sola VM. Desafortunadamente, esta aplicación crea un punto de falla único. Si esa VM no está disponible, entonces la aplicación no está disponible, y eso conduce a la insatisfacción y hambre del cliente.

Si conduce un automóvil, es muy probable que cuente con una llanta de repuesto por si sufre un pinchazo. Si utiliza un equipo portátil o una tableta, es muy probable que conecte el dispositivo a un cargador si la batería se agota en medio del trabajo. En casa o en su apartamento, ¿tiene bombillas de repuesto en caso de que se apague alguna de las luces? ¿Y linterna o velas en caso de que haya un apagón?
A la mayoría de la gente le gusta tener algún tipo de plan de redundancia o respaldo,
tanto en la vida cotidiana como, especialmente, en TI. Si está listo para cambiar una llanta del automóvil o si tiene una bombilla de repuesto, puede manejar interrupciones y fallas con una interrupción mínima. Si diseña y compila sus aplicaciones con redundancia, proporciona un alto nivel de disponibilidad a sus clientes, lo que minimiza, o incluso oculta, cualquier interrupción que sufra la aplicación. Todos los centros de datos de Azure están construidos para alta disponibilidad. Suministro eléctrico de respaldo, varias conexiones de red y matrices de almacenamiento con discos de repuesto son solo algunos de los conceptos básicos de redundancia que Azure proporciona y administra para usted. Sin embargo, toda la redundancia que ofrece Azure no será suficiente si ejecuta su aplicación en una sola VM. Para brindarle flexibilidad y control para que su aplicación esté altamente disponible, existen dos funciones principales para las cargas de trabajo de IaaS:
– Zona de disponibilidad: permite distribuir VM en segmentos físicamente aislados de una región de Azure para maximizar aún más la redundancia de la aplicación. Las zonas también pueden proporcionar alta disponibilidad a recursos de red como direcciones IP públicas y equilibradores de carga.
– Conjunto de disponibilidad: permite agrupar las VM de forma lógica para distribuirlas a través de un único centro de datos de Azure y minimizar los cortes producto de actualizaciones de mantenimiento o interrupciones.
Para la mayoría de las implementaciones de aplicaciones nuevas en Azure, le recomendamos que planifique utilizar zonas de disponibilidad. Este enfoque ofrece flexibilidad para distribuir la aplicación y proporciona redundancia a los recursos de red que a menudo son fundamentales para que los clientes accedan a las VM subyacentes en última instancia. Para ver cómo funciona cada uno de estos enfoques, analicémoslos con más profundidad.

Redundancia de infraestructura con zonas de disponibilidad
Las zonas de disponibilidad son centros de datos físicamente separados que operan en instalaciones básicas independientes, como la conectividad de red y de energía. Cada región Azure compatible con zonas de disponibilidad proporciona tres zonas. Usted crea sus recursos en estas zonas y a través de ellas. La figura se muestra cómo se pueden distribuir los recursos Azure a través de zonas de disponibilidad.

Con las zonas de disponibilidad, sus aplicaciones pueden tolerar que se caiga un centro de datos completo de Azure. Seguro tendría que suceder un acontecimiento importante para ocurriera esto, ¡pero incluso eso es posible!
En implementaciones de aplicaciones grandes, puede crear más de una VM en cada zona de disponibilidad. Varias máquinas virtuales en una zona de disponibilidad se distribuyen automáticamente en el hardware disponible dentro de la zona. No hay nada que tenga que configurar o que pueda controlar. Incluso si una actualización de mantenimiento o una falla del equipo dentro de una zona afectaran a todas las VM que se ejecutan en la zona, recuerde que las zonas están físicamente aisladas entre sí: las VM de otra zona continuarían funcionando.
Ahora, si tiene mucha mala suerte, ¿podrían sus VM en diferentes zonas tener actualizaciones de mantenimiento al mismo tiempo? Sí, pero es poco probable. Las zonas de una región tienen ciclos de actualización intercalados. Las actualizaciones se realizan en una zona; una vez completadas, se realizan en la siguiente zona. Las zonas de disponibilidad proporcionan un alto nivel de abstracción y redundancia, y debe mirar su aplicación en toda la implementación, no solo donde residen las VM en una zona.
La inclusión de los recursos de red virtuales en zonas de disponibilidad es mucho más importante de lo que puede parecer al principio. En la figura se muestra lo que sucedería si el centro de datos no estuviera disponible para los recursos de red, como una dirección IP pública y un equilibrador de carga que se ejecute a través de zonas de disponibilidad.

Hablaré más sobre equilibradores de carga en el capítulo 8, pero por ahora, todo lo que necesita entender es que el equilibrador de carga distribuye el tráfico a través de todas las VM disponibles que se conectan a él. Las VM reportan su estado a intervalos establecidos y el equilibrador de carga deja de distribuir el tráfico a una VM que informa estar no disponible. Con un equilibrador de carga que funciona a través de zonas de disponibilidad, una interrupción en un centro de datos de Azure hará que las VM queden no disponibles y se saquen de la rotación del equilibrador de carga.
Una dirección IP pública que abarca zonas de disponibilidad proporciona un único punto de entrada para que los clientes lleguen a su equilibrador de carga y luego se distribuyan a una VM disponible. En una implementación de aplicación donde la dirección IP pública reside en un solo centro de datos de Azure, si ese centro de datos sufre un problema, ningún cliente puede acceder a la dirección IP pública. El cliente no puede utilizar su aplicación, aunque haya VM disponibles para atender las solicitudes de los clientes.
Los recursos que pueden utilizar las zonas de disponibilidad incluyen tanto los servicios zonales como los servicios con redundancia de zona:
– Los servicios zonales son para cosas como las máquinas virtuales, una dirección IP pública o un equilibrador de carga. Todo el recurso en sí funciona dentro de una zona determinada y puede funcionar por sí mismo si otra zona no está disponible.
– Los servicios con redundancia de zona son para recursos que pueden replicarse automáticamente entre zonas, como el almacenamiento con redundancia de zona y las bases de datos SQL. El recurso completo no se ejecuta en una zona determinada, sino que sus datos se distribuyen entre las zonas para que siga estando disponible si una zona tiene un problema.
La compatibilidad con la zona de disponibilidad está disponible para más de 20 servicios de Azure en más de diez regiones. El número de servicios y regiones que se integran con las zonas de disponibilidad sigue creciendo. Sin embargo, dadas las limitaciones de la región, puede haber ocasiones en las que la compatibilidad con la zona de disponibilidad no esté disponible para recursos básicos como las máquinas virtuales. En esos casos, hay otro tipo de redundancia de máquina virtual que se puede utilizar en cualquier región.

Creación de recursos de red en una zona de disponibilidad
Para comenzar a ver algo de esta disponibilidad y redundancia en acción, creemos algunos recursos comunes, como una dirección IP pública y un equilibrador de carga, y luego las máquinas virtuales. El objetivo aquí es ver que no hay que hacer mucha configuración para aprovechar las zonas de disponibilidad en Azure. Estos son ejemplos sencillos, pero constituyen el núcleo de la mayoría de los entornos de aplicación que se implementan.
Las direcciones IP públicas y los equilibradores de carga se pueden crear en uno de los dos niveles disponibles: básico y estándar. La diferencia principal es que el nivel estándar permite que el recurso de red utilice zonas de disponibilidad. De forma predeterminada, una dirección IP pública estándar o equilibrador de carga es automáticamente redundante a nivel regional. No tiene que completar ninguna configuración adicional. La plataforma Azure almacena de forma centralizada los metadatos para el recurso dentro de la región que especifique y se asegura de que el recurso continúe funcionando si una zona no está disponible.
No se preocupe demasiado por lo que sucede con el equilibrador de carga y los recursos de red en este momento. Recuerde lo que dijimos al principio: estos dos o tres capítulos se construyen uno sobre el otro. En el capítulo 8, nos adentramos en los equilibradores de carga, y todo esto debería empezar a cobrar más sentido.

Pruébelo ahora
Complete los siguientes pasos para crear recursos de red redundantes en las zonas de disponibilidad:
1 Seleccione el icono de Cloud Shell en la parte superior del panel de Azure Portal.
2 Cree un grupo de recursos, como azuremolchapter7az:
az group create –name azuremolchapter7az –location westeurope
3 Cree una dirección IP pública estándar en el grupo de recursos. De forma predeterminada, se creará una dirección IP pública básica y se asignará a una sola zona. El parámetro –sku standard le indica a Azure que cree un recurso de zona transversal redundante:

az network public-ip create \
–resource-group azuremolchapter7az \
–name azpublicip \
–sku standard

4 Cree un equilibrador de carga que abarque las zonas de disponibilidad. Como ya lo mencionamos, de forma predeterminada se crearía un equilibrador de carga básico y se asignaría a una sola zona, pero no es el diseño de alta disponibilidad ideal para sus aplicaciones. Especifique un SKU de carga estándar para crear un equilibrador de carga con redundancia de zona, como se indica a continuación:

az network lb create \
–resource-group azuremolchapter7az \
–name azloadbalancer \
–public-ip-address azpublicip \
–sku standard

Creación de VM en una zona de disponibilidad
Para crear una VM en una zona de disponibilidad, especifique la zona donde se ejecutará la VM. Para implementar varias VM, es ideal crear y utilizar una plantilla. La plantilla define y distribuye las zonas para cada una de las VM. A medida que crezca la demanda de los clientes por su pizzería en línea, puede actualizar la plantilla con el número de VM que quiere ahora y luego vuelva a implementar la plantilla. Las nuevas VM se distribuyen automáticamente a través de las zonas y no es necesario rastrear manualmente las zonas en las que se ejecutan las VM. En el laboratorio de fin del capítulo, se utiliza una plantilla para crear y distribuir automáticamente varias VM. Para ver el proceso lógico para especificar una zona para una VM, vamos a crear una VM y especificar manualmente la zona.
Pruébelo ahora
Complete los siguientes pasos para crear una VM en una zona de disponibilidad:
1 En Azure Portal, seleccione el icono Cloud Shell en la parte superior del panel.
2 Cree una VM con el comando az vm create que usó en capítulos anteriores. Use el parámetro –zone para especificar si la VM se debe ejecutar en la zona 1, 2 o 3. El siguiente ejemplo crea una VM denominada zonedvm en la zona 3:

az vm create \
–resource-group azuremolchapter7az \
–name zonedvm \
–image ubuntults \
–size Standard_B1ms \
–admin-username azuremol \
–generate-ssh-keys \
–zone 3

Crear una VM demora unos minutos. Cuando termine el proceso, el resultado del comando indica la zona en la que se ejecuta la VM. También puede ver esta información con el comando az vm show:

az vm show \
–resource-group azuremolchapter7az \
–name zonedvm \
–query zones

NOTA Los ejemplos en estos ejercicios «Pruébelo ahora» son simples, pero están diseñados para mostrarle que las zonas requieren poca configuración para poder utilizarse. No integró el equilibrador de carga con redundancia de zona con la VM, pero en el capítulo 8 compilará un entorno de aplicación más utilizable que se distribuye a través de zonas de disponibilidad. El objetivo aquí es mostrarle que la plataforma Azure maneja la redundancia y la distribución de sus recursos, para que pueda centrarse en la aplicación en sí.

Redundancia de VM con conjuntos de disponibilidad
Las zonas de disponibilidad son excelentes cuando se diseña la redundancia en un conjunto más amplio de recursos que conforman sus aplicaciones y cargas de trabajo. Le recomiendo que, en la medida de lo posible, las utilice para las nuevas cargas de trabajo. Sin embargo, hay ocasiones en las que no es necesario que toda la zona de recursos sea redundante. O puede que quiera crear máquinas virtuales en una región de Azure que no tenga actualmente soporte de zona de disponibilidad.
Si solo desea proporcionar redundancia para VM, los conjuntos de disponibilidad lo tienen cubierto. Su funcionamiento es comprobado, son confiables y están disponibles en todas las regiones. Los conjuntos de disponibilidad contienen un grupo lógico de VM que indica a la plataforma Azure el hardware subyacente en el que se ejecutan esas VM y que se debe seleccionar cuidadosamente. Si crea dos VM que se ejecutan en el mismo servidor físico y un servidor falla, ambas VM dejan de funcionar. Con potencialmente decenas de miles o más servidores físicos en un centro de datos de Azure, es muy improbable que tenga ambas VM en el mismo servidor, ¡pero es posible! Puede no ser un error, sino una actualización de mantenimiento que haga que el servidor físico esté no disponible brevemente.
¿Qué pasa si sus VM se ejecutan en el mismo rack, conectados al mismo equipo o red de almacenamiento? Vuelve al punto de falla único sobre el que hablamos al comienzo del capítulo.
Los conjuntos de disponibilidad permiten a la plataforma Azure crear sus VM en grupos lógicos denominados dominios de error y dominios de actualización. Estos dominios lógicos permiten a la plataforma Azure comprender los límites físicos de los grupos de hardware para asegurarse de que las VM se distribuyan uniformemente a través de ellas. Si parte del hardware sufre un problema, solo se verán afectadas unas pocas VM de su conjunto de disponibilidad. O si hay actualizaciones de mantenimiento que se apliquen al hardware físico, el mantenimiento afectará solo a algunas de las VM. En la figura 7.4, se muestra la relación entre el hardware físico y los dominios de error y los dominios de actualización lógicos dentro de un conjunto de disponibilidad.
Las zonas de disponibilidad hacen el mismo tipo de distribución bajo el capó, pero se abstraen y no se exponen. Incluso con los conjuntos de disponibilidad, no hay mucho que se pueda configurar. Pero es útil saber lo que ocurre en segundo plano.

Dominios de error
Un dominio de error es un grupo lógico de hardware en un centro de datos de Azure. Contiene hardware que comparte alimentación o equipo de red. Usted no controla lo que son estos dominios de error, y no hay nada que deba configurar en la VM. La plataforma Azure rastrea los dominios de error en los que se colocan sus VM y distribuye las nuevas VM en estos dominios de error para que siempre disponga de VM si falla la alimentación o el conmutador de red.

Las VM que utilizan discos administrados (recuerde, ¡todas las VM deben utilizar discos administrados!) también respetan los límites lógicos de los dominios de error y distribución. La plataforma Azure asigna de forma lógica clústeres de almacenamiento a los dominios de error para garantizar que, a medida que las VM se distribuyan en grupos de hardware, los discos administrados también se distribuyan a través de hardware de almacenamiento. La redundancia de VM en el hardware del servidor no tendría sentido si existiera la posibilidad de que todos los discos administrados terminaran en un único clúster de almacenamiento. Y sí, los discos administrados también pueden utilizarse con las zonas de disponibilidad.

Dominios de actualización
Mientras que los dominios de error crean un grupo lógico de hardware para proteger contra fallas de hardware, los dominios de actualización protegen contra el mantenimiento rutinario. Para proporcionar esta protección, un dominio de error a su vez se divide lógicamente en dominios de actualización. Reitero, no hay nada que configurar aquí. Los dominios de actualización son una manera para que la plataforma Azure entienda cómo debe distribuir VM a través de su conjunto de disponibilidad.
Los ingenieros de Azure realizan mantenimiento (principalmente automatizado) y aplican actualizaciones en todo el hardware físico en un dominio de actualización y, a continuación, realizan el mismo mantenimiento en todo el hardware del siguiente dominio de actualización. Este trabajo de mantenimiento se intercala en los dominios de actualización para asegurarse de que las VM de un conjunto de disponibilidad no se ejecuten en hardware que al mismo tiempo esté en mantenimiento. Es el mismo tipo de proceso que vimos con las zonas de disponibilidad; la distribución de sus recursos significa que no puede tener un escenario en el que todo el hardware subyacente para sus recursos se esté actualizando al mismo tiempo.
No hay ninguna relación entre los dominios en varios conjuntos de disponibilidad. Los recursos físicos que componen los dominios de error y actualización en un conjunto de disponibilidad pueden no ser los mismos para un segundo conjunto de disponibilidad. Esto significa que si crea varios conjuntos de disponibilidad y distribuye sus VM a través de ellos, el dominio de error 1, por ejemplo, no siempre contiene el mismo hardware físico.

Distribución de las VM en un conjunto de disponibilidad
Vayamos paso a paso y veamos cómo se distribuyen las VM en los dominios lógicos de error y de actualización que componen un conjunto de disponibilidad. De esta manera, tiene varias VM que pueden ejecutar su pizzería, ¡y los clientes no pasarán hambre!
Pruébelo ahora
Para ver los conjuntos de disponibilidad en acción, complete los siguientes pasos para implementar una plantilla de Resource Manager:
1 Abra un navegador web y vaya a una plantilla de Resource Manager desde el repositorio de ejemplos de GitHub en https://github.com/fouldsy/azure-mol-samples-2nd-ed/tree/master/ 07/availability-set y luego seleccione el botón Implementar en Azure. En este ejercicio, utilizará una plantilla para poder implementar rápidamente las VM y explorar cómo se distribuyen en el conjunto de disponibilidad.
Se abre Azure Portal y solicita algunos parámetros.
2 Seleccione para crear nuevo grupo de recursos y luego escriba un nombre, como azuremolchapter7. Seleccione una región y, a continuación, proporcione los datos de la clave SSH (puede obtenerla en este Cloud Shell con cat ~/.ssh/id_rsa.pub).
La plantilla crea un conjunto de disponibilidad que contiene tres VM, las que se distribuyen a través de los dominios de error y actualización lógicos. Basándose en lo que aprendió sobre Resource Manager en el capítulo 6, esta plantilla utiliza la función copyindex() para crear varias VM y NIC.
3 Para aceptar que desea crear los recursos detallados en la plantilla, marque la casilla «Acepto los términos y condiciones indicados anteriormente» y, a continuación, seleccione Comprar.
Toma unos minutos crear las tres VM en el conjunto de disponibilidad. Deje que continúe la implementación en el portal mientras lee el resto de la sección.
Cuando la plantilla comienza a implementarse, se crea un conjunto de disponibilidad y se asigna el número de dominios de actualización y de error que solicitó. Las siguientes propiedades se definieron en la plantilla de ejemplo:

“properties”: {
“platformFaultDomainCount”: “2”,
“platformUpdateDomainCount”: “5”,
“managed”: “true”
}

Estas propiedades crean un conjunto de disponibilidad con dos dominios de error y cinco dominios de actualización, como se muestra en la figura, e indican que las VM deben utilizar discos administrados, así que recuerde respetar la distribución del disco. La región seleccionada para el conjunto de disponibilidad determina el número máximo de dominios de error y de actualización. Las regiones admiten 2 o 3 dominios de error y hasta 20 dominios de actualización.

A medida que crea más VM en un conjunto de disponibilidad, debe considerar la cantidad de dominios de actualización que se usarán. Por ejemplo, cinco dominios de actualización significa que hasta un 20 % de las VM puede no estar disponible a causa de mantenimiento:
– Digamos que tiene 10 VM en su conjunto de disponibilidad. Dos de esas VM pueden estar en mantenimiento al mismo tiempo. Si desea permitir que solo una VM esté en mantenimiento a la vez, necesitará crear 10 dominios de actualización. Cuantos más dominios de actualización crea, más tiempo estará la aplicación potencialmente en estado de mantenimiento.
– Continuemos con el ejemplo anterior de 10 máquinas virtuales en 10 dominios de actualización. Ahora existe la posibilidad de que se produzcan interrupciones en sus aplicaciones hasta que los 10 dominios de actualización hayan completado su ciclo de mantenimiento. Si solo tiene 5 dominios de actualización, ese plazo de mantenimiento se reduce. No es necesariamente malo tener un período de mantenimiento más largo; se trata más bien de cuál es su tolerancia para funcionar potencialmente a menos de la capacidad total.
Es importante recordar que estos dominios de actualización y ciclos de mantenimiento son los que realiza la propia plataforma Azure. También debe considerar sus propias necesidades de actualización y los plazos de mantenimiento.

Cuando se crea la primera VM, la plataforma Azure busca para ver dónde estaría disponible la primera posición de implementación. Este es el dominio de error 0 y dominio de actualización 0, como se muestra en la figura de mas abajo
Cuando se crea la segunda VM, la plataforma Azure busca para ver dónde estaría disponible la siguiente posición de implementación. Ahora es el dominio de error 1 y dominio de actualización 1, como se muestra en la figura la siguientes figuras.

Su plantilla crea tres VM, así que ¿qué cree que pasa después? La plataforma Azure vuelve a buscar dónde estaría disponible la siguiente posición de implementación. Ha creado solo dos dominios de error, así que la VM se crea de nuevo en el dominio de error 0, pero en un dominio de actualización diferente que la primera VM. La tercera VM se crea en el dominio de actualización 2.

Las VM 0 y 2 están en el mismo dominio de error, por lo que una falla de hardware podría posiblemente afectar a ambas VM. Pero el mantenimiento rutinario solo afecta a una de esas VM a la vez, porque están distribuidas a través de dominios de actualización. Si continúa y crea más VM, la plataforma Azure continuará distribuyéndolas a través de diferentes dominios de error y de actualización. Cuando se utilizan los cinco dominios de actualización, la sexta VM se crea de nuevo en el dominio 0 de actualización y el ciclo continúa.

Visualización de distribución de las VM en un conjunto de disponibilidad
Ahora que entiende la teoría sobre cómo se distribuyen las VM en los dominios de error y de actualización en un conjunto de disponibilidad, veamos qué ha sucedido con la implementación de su plantilla de Resource Manager.
Pruébelo ahora
Complete los siguientes pasos para ver cómo se distribuyen las VM en un conjunto de disponibilidad:
1 Busque y seleccione Grupos de recursos en la barra de navegación del lado izquierdo de Azure Portal.
2 Elija el grupo de recursos que creó para la implementación de la plantilla, como azuremolchapter7.
3 Seleccione el conjunto de disponibilidad de la lista de recursos, como azuremolavail-abilityset.
En la ventana Información general, hay una lista de VM y sus dominios asociados a errores y actualizaciones.

Si es observador, puede ver que las VM no se alinean perfectamente con el orden esperado de los dominios de error y actualización. ¿Hay algún error? Probablemente no. Si examina el ejemplo en la figura y lo compara con los conceptos que aprendió, esperaría que las VM se distribuyeran como se muestra en la tabla de a continuación.

Entonces, ¿qué salió mal? Nada. Vuelva a pensar en cómo Resource Manager crea recursos a partir de una plantilla. La plataforma Azure no espera a que se cree la primera VM antes de que se pueda crear la segunda. Las tres VM se crean al mismo tiempo. Entonces, puede haber fracciones de segundo de diferencia en que la VM se asocia primero a un conjunto de disponibilidad. No importa cuál sea el orden, porque no puede controlar lo que representan los dominios de error y actualización subyacentes. Depende de la plataforma Azure. Solo tiene que asegurarse de que sus VM estén distribuidas, no dónde.

No, prefiero algo más organizado
Si el comportamiento de creación en serie de VM le molesta y debe distribuir las VM en un orden organizado, puede indicarle a Resource Manager que cree VM en serie en lugar de hacerlo en paralelo. En este modo, las VM se crean una tras otra, por lo que aumenta el tiempo de implementación. Para habilitar este comportamiento en serie, use «mode»: «serial» en su plantilla como parte de la función copyIndex(). Eso debiera distribuir las VM de una manera organizada y secuencial.

y bien hasta aquí la entrada de hoy, mañana mas.. aunque es fiesta en España a ver si lo puedo subir