lunes, 11 de diciembre de 2017

Topología de red

La topología de red se define como la cadena de comunicación usada por los nodos que conforman una red para comunicarse. Un ejemplo claro de esto es la topología de árbol, la cual es llamada así por su apariencia estética, por la cual puede comenzar con la inserción del servicio de internet desde el proveedor, pasando por el router, luego por un switch y este deriva a otro switch u otro router o sencillamente a los hosts (estaciones de trabajo), el resultado de esto es una red con apariencia de árbol porque desde el primer router que se tiene se ramifica la distribución de internet dando lugar a la creación de nuevas redes y/o subredes tanto internas como externas. Además de la topología estética, se puede dar una topología lógica a la red y eso dependerá de lo que se necesite en el momento.

En algunos casos se puede usar la palabra arquitectura en un sentido relajado para hablar a la vez de la disposición física del cableado y de cómo el protocolo considera dicho cableado. Así, en un anillo con una MAU podemos decir que tenemos una topología en anillo, o de que se trata de un anillo con topología en estrella.

La topología de red la determina únicamente la configuración de las conexiones entre nodos. La distancia entre los nodos, las interconexiones físicas, las tasas de transmisión y/o los tipos de señales no pertenecen a la topología de la red, aunque pueden verse afectados por la misma. Redes de araña

La topología en estrella es la posibilidad de fallo de red conectando todos los nodos a un nodo central. Cuando se aplica a una red basada en la topología estrella este concentrador central reenvía todas las transmisiones recibidas de cualquier nodo periférico a todos los nodos periféricos de la red, algunas veces incluso al nodo que lo envió. Todos los nodos periféricos se pueden comunicar con los demás transmitiendo o recibiendo del nodo central solamente. Un fallo en la línea de conexión de cualquier nodo con el nodo central provocaría el aislamiento de ese nodo respecto a los demás, pero el resto de sistemas permanecería intacto. El tipo de concentrador hub se utiliza en esta topología.


La desventaja radica en la carga que recae sobre el nodo central. La cantidad de tráfico que deberá soportar es grande y aumentará conforme vayamos agregando más nodos periféricos, lo que la hace poco recomendable para redes de gran tamaño. Además, un fallo en el nodo central puede dejar inoperante a toda la red. Esto último conlleva también una mayor vulnerabilidad de la red, en su conjunto, ante ataques.

Si el nodo central es pasivo, el nodo origen debe ser capaz de tolerar un eco de su transmisión. Una red en estrella activa tiene un nodo central activo que normalmente tiene los medios para prevenir problemas relacionados con el eco.

Una topología en árbol (también conocida como topología jerárquica) puede ser vista como una colección de redes en estrella ordenadas en una jerarquía. Éste árbol tiene nodos periféricos individuales (por ejemplo hojas) que requieren transmitir a y recibir de otro nodo solamente y no necesitan actuar como repetidores o regeneradores. Al contrario que en las redes en estrella, la función del nodo central se puede distribuir.


Como en las redes en estrella convencionales, los nodos individuales pueden quedar aislados de la red por un fallo puntual en la ruta de conexión del nodo. Si falla un enlace que conecta con un nodo hoja, ese nodo hoja queda aislado; si falla un enlace con un nodo que no sea hoja, la sección entera queda aislada del resto.

Para aliviar la cantidad de tráfico de red que se necesita para retransmitir todo a todos los nodos, se desarrollaron nodos centrales más avanzados que permiten mantener un listado de las identidades de los diferentes sistemas conectados a la red. Éstos switches de red “aprenderían” cómo es la estructura de la red transmitiendo paquetes de datos a todos los nodos y luego observando de dónde vienen los paquetes respuesta.

Cookie Informatica

Pocas palabras en los últimos tiempos habrán hecho dar más vueltas a quienes buscan, pese a todo, una forma de decir las cosas en su propia lengua. Una cookie es un pequeño fichero que un sitio web envía al disco duro de la persona que lo visita, y que informa sobre lo que el usuario ha hecho en él. Aparecieron por primera vez en el navegador Netscape. Gracias a las cookies la librería virtual sabe quiénes somos en visitas sucesivas, y despliega para recibirnos las novedades en cocina oriental que son de nuestro agrado. En realidad la cookie no dice nada sobre el usuario que él ya no haya revelado en su navegación, aunque quien vaya a sitios publicitarios o pornográficos puede encontrar que dejan demasiadas huellas en su ordenador...

HTTP server mod cluster - mod balancer

mod_cluster.conf
########################################################
# mod_proxy_balancer should be disabled when mod_cluster is used
#LoadModule proxy_cluster_module modules/mod_proxy_cluster.so
LoadModule slotmem_module modules/mod_slotmem.so
LoadModule manager_module modules/mod_manager.so
LoadModule advertise_module modules/mod_advertise.so

MemManagerFile /var/cache/mod_cluster

<IfModule manager_module>
  Listen hostname.companieName.com:6666
  NameVirtualHost hostname.companieName.com:6666
  <VirtualHost hostname.companieName.com:6666>
     ManagerBalancerName prod
     ServerAdvertise Off
     ServerName hostname.companieName.com
     ErrorLog "/etc/httpd/logs/6666-error_log"
     CustomLog "/etc/httpd/logs/6666-access_log" common

    <Location />
       Order deny,allow
       Allow from all
    </Location>

    KeepAliveTimeout 60
    MaxKeepAliveRequests 0
    EnableMCPMReceive
  </VirtualHost>

  Listen hostname.companieName.com:8080
  <VirtualHost hostname.companieName.com:8080>
    <Location /modcluster>
      SetHandler mod_cluster-manager
      Order deny,allow
      Deny from all
      Allow from all
      Options -Indexes
    </Location>
  </VirtualHost>
</IfModule>
#########################################################






mod_proxy.conf
##########################################################
LoadModule proxy_cluster_module modules/mod_proxy_cluster.so

NameVirtualHost hostname.companieName.com:80

<IfModule mpm_worker_module>
  ThreadLimit           120
  ServerLimit           10
  StartServers          3
  MinSpareThreads       5
  MaxSpareThreads       20
  MaxClients            1200
  ThreadsPerChild       120
  MaxRequestsPerChild   0
</IfModule>

<IfModule mpm_prefork_module>
  ServerLimit           1200
  StartServers          5
  MinSpareServers       5
  MaxSpareServers       20
  MaxClients            1200
  MaxRequestsPerChild   0
</IfModule>

<VirtualHost hostname.companieName.com:80 >
  TimeOut 1200
  ProxyTimeout 1200
  ProxyPass / balancer://prod/ stickysession=JSESSIONID|jsessionid nofailover=On
  ProxyPassReverse / balancer://prod/
  ProxyPreserveHost On

  ServerName hostname.companieName.com

  ErrorLog "/etc/httpd/logs/error_log"
  CustomLog "/etc/httpd/logs/access_log" common

  <Location />
    Order deny,allow
    Allow from all
  </Location>
</VirtualHost>
#############################################################

miércoles, 22 de noviembre de 2017

Migración de aplicaciones a RH OpenShift



WebLogic

Precondiciones:


  1. WebLogic >= 12.1.2
  2. JDK compatible con WebLogic
  3. OpenShift 3.x o más actual
  4. FPM >= 1.1.0 (Para la creación del RPM)

Pasos

  1. Copia tu JDK dentro del directorio jdk/.
  2. Ejecuta make-cart.sh, en la ruta de instalación de WebLogic.
  3. Despliega los nodos de OpenShift.
No podemos ejecutar el instalador de WebLogic como root, así que ejecute crear sus directorios de instalación antes de ejecutarlo y otorgue permisos al usuario de la instalación para evitar errores. Los directorios predeterminados creados son:



  • /opt/weblogic-openshift/
  • /usr/libexec/openshift/cartridges/openshift-weblogic-cartridge/
Habilitar rngd es muy recomendable ya que WebLogic usa  /dev/random mucho durante la instalación y el inicio de dominios.

yum install rng-tools; echo 'EXTRAOPTIONS="-r /dev/urandom -o /dev/random -b"' >> /etc/sysconfig/rngd; chkconfig rngd on; service rngd start

.NET

Precondiciones:


RH Openshift actualmente  soporta el estándar .NET Standard 2.0

Los paquetes de ASP.NET Core 2.0 tienen como base
 .NET Standard 2.0. 
Se puede hacer referencia a los paquetes mediante otras bibliotecas de .NET Standard 2.0 y se pueden ejecutar en implementaciones compatibles con .NET Standard 2.0 de. NET, como .NET Core 2.0 y .NET Framework 4.6.1.x

Pasos
  1. Implementación de un ambiente de OpenShift.
  2. Asignar una cuenta al área de desarrollo.
  3. Para que su proyecto ASP.NET esté listo para OpenShift, todo lo que necesita es agregar 4 líneas más de código en Program.cs 

...
using Microsoft.Extensions.Configuration; // 1st line added

....
var config = new ConfigurationBuilder().AddEnvironmentVariables("").Build();
// 2nd line added

var url = config["ASPNETCORE_URLS"] ?? "http://*:8080";
// 3rd line added

...
.UseUrls(url) // 4th line added
}


  1. Los cambios realizados configuran ASP para escuchar el puerto 8080.
  2. Generar un repositorio GIT



lunes, 9 de enero de 2017

Criterios de aceptación

Un criterio de aceptación es un parámetro por el se cuantifica si una historia de Usuario ha sido desarrollada según la expectativa del Cliente y si se ha conseguido el objetivo.
p.e. Si se requiere un servicio que envíe un ID y regrese el nombre de una persona.

Deberán ser definidos lo antes posible por que complementan la historia de usuario, y ayudan al equipo de análisis, integración y desarrollo a entender mejor cómo se espera a que el producto final se comporte o se visualice, como un todo, y también los subproductos, para lo cual se tendrán que identificar las expectativas y dejar claro antes de empezar a desarrollar, y del mismo modo el desarrollo sera mas facil, asi como la definición de las historias de usuario se realiza de una manera más fácil rápida y precisa.

En los criterios de aceptación se podrá visualizar una guía para el que realiza los test, ya que deberán cubrir los casos de uso mas comunes:
Happy Path
Cornet Case

El método SMART. SMART significa Specific (Especifico), Measurable (Medible), Achievable (Alcanzable), Relevant (Relevante) y Time-bound (Temporalmente limitado).
Se utiliza para indicar la calidad de un criterio de aceptación ya que tendrá que cumplir con los elementos

Las técnicas para escribir criterios de aceptación son las siguientes:

    Técnica de comportamiento: Con respecto a una acción, tiempo y evento, entonces se tiene una consecuencia, de esta forma se consigue una estructura que se traslada fácilmente a los test automáticos.

    Técnica de escenarios: Se define el (Happy Path) algunos trayectos alternativos de la funcionalidad o comportamiento, y se deberá indicar como el usuario interactúa, ejecutando o intentando ejecutar los diversos pasos o secuencias en los trayectos indicados.
    Se restringirá a los trayectos  indicados únicamente para que el usuario procesa y el sistema corresponda, eliminando información y flujos no necesarios.
    Tiene la ventaja de que permite al equipo de desarrollo ir dando por hechas las funcionalidades y los casos que de ella se origina mientras las van implementando. Su mayor beneficio es que estos criterios de aceptación no pueden ser trasladados directamente de la historia de usuario a un test de aceptación automático. Eso puede resultar en escribir un test de aceptación que compruebe más de un criterio de aceptación, que es lo recomendado. Además, nos permiten usar más de un usuario para describir el escenario del criterio.

El uso de Criterios de aceptación aporta muchas ventajas, las que me parecen más importantes:

    Fomentan la comunicación entre Cliente y equipo.
    Ayudan en la estimación de la historia al imponer límites.
    Garantizan que el trabajo realizado será lo solicitado por el Cliente.
    Reducen las necesidad de hacer consultas al Cliente durante el sprint, con la consiguiente pérdida de productividad del equipo y del Cliente.


By Psehgaft