Archive for January, 2009
Jan
Cisco ofrecerá Servidores con VMware
Enviado por (0) Comment
Un nuevo player entra al desafio de captar más clientes en el segmento de virtualización. Hablamos de Cisco quien ha firmado un acuerdo más que importante con VMware para comenzar a distribuir servidores con ESX a partir del primer trimestre del 2009.Claro está que VMware y Cisco siempre se llevaron bien, incluso es puúlico que ambos trabajaron en conjunto para perfeccionar la capa de virtualización de networking, características que sus competidores no tienen totalmente desarrolladas, sin contar que cisco posee el 2 % de las acciones de VMware.
Esta noticia pone en especial atención a proveedores como HP, IBM y DELL quienes proveen hoy las soluciones de hardware para soportar la plataforma de VMware, y son quienes hoy cuentan con la mayor base instalada de clientes con virtualización.
- Bookmark :
- Digg
- del.icio.us
- Stumbleupon
- Redit it
Jan
Cómo trabaja la actualización de Firmas en eTrust ITM 8.x?
Existen 3 componentes en una arquitectura de eTrust ITM 8.x:
- Servidor ITM
- Servidor de Redistribución (podría ser el mismo ITM en una pequeña red ú otros servidores en una red más extensa ó con enlaces WAN).
- Agentes (instalados en las pcs).
Cada agente, tiene configurado por política ó manualmente, un Servidor de donde descargar las actualizaciones de firmas. El agente se conecta a dicho Servidor (web de CA, Servidor ITM ó Servidor de Redistribución) y descarga los paquetes para luego actualizar sus firmas y componentes.
Hasta acá, un violín…
Por Seguridad, quiero actualizar la firma de mis pcs ANTES de conectarla a la Red, cómo hago?
Lamentablemente CA no cuenta con ningún ejecutable del estilo del viejo Norton Antivirus que se podría pasar en un Pendrive a la pc recién instalada y dejar el AV actualizado a último momento sin necesidad de exponerla en la red ni Interent. Yo insisto en NO exponer una PC recién instalada, y cómo hago???
- Identificar alguna otra PC con agente de eTrust ITM 8.x que tenga la firma actualizada al día de hoy.
- Copiar a un Pendrive (obviamente limpio de virus) la carpeta X:\Program Files\CA\SharedComponents\ScanEngine completa (X: es la unidad de disco donde se instaló el Soft).
- En la nueva PC, Bajar los servicios INOTASK, INORT, e INORPC (net stop SERVICIO)
- Pegar la carpeta ScanEngine y reemplazar la existente en la PC recién instalada.
- Levantar los servicios INOTASK, INORT, e INORPC (net start SERVICIO).
Para chequear la nueva versión de firmas, hacer click derecho en el ícono del RealTime Monitor en el Systray, y click en “About” ó “Acerca de…”. Pueden comparar la versión que muestra con la de otro agente que esté actualizado y lo podrán comprobar.
Espero les sea de utilidad y maximizen la seguridad de sus nuevas PCs.
Saludos!!!!
Patricio Limeres
- Bookmark :
- Digg
- del.icio.us
- Stumbleupon
- Redit it
Jan
Entendiendo la arquitectura de Unicenter DSM, sabemos que un Scalability Server es el nexo entre el DSM Manager y los Agentes.
Las Mejores prácticas dictan que un Scalability Server reduce el tráfico entre el Manager y Agentes. Esto aplica perfecto cuando entre Agentes y Manager hay un enlace WAN.
Ahora bien, hasta cuánto de pequeño puede ser el enlace entre Manager y Scalability?
NOTA: Estos tips están destinados a Consultores que ya conocen la herramienta, su funcionamiento y Arquitectura.
He tenido experiencias en enlaces de hasta 64 kbps. El deploy del Scalability funcionó bien utilizando “Deploy Infrastructure” en el Explorer del Manager, y el Stage de paquetes lo tuve que hacer manualmente. Aquí los pasos a seguir:
1- Desde el Explorer del Manager, modificar las siguientes políticas Default:
. DSM/Manager/Infrastructure Deployment/Job Failure Timeout Inteval. Esta política tiene un valor de 120 minutos por default. Se expande para que el job de deploy de un Scalability finalice correctamente. De lo contrario, el job fallará debido al pobre enlace.
. DSM/Manager/Infrastructure Deployment/Message Delivery Timeout interval. Setearlo en 10 minutos es suficiente.
. DSM/Manager/Infrastructure Deployment/Primer timeout Interval. 30 Minutos es suficiente.
NOTA: los valores mencionados no garantizan el funcionamiento, se debe modificar de acuerdo a cada situación particular.
2- Ejecutar el job de Deploy de Scalability Server. Esta tarea, en mi caso, con 64kbps demoró 7 horas y media. Puede variar considerablemente. Aquí se ve reflejado el cambio de las políticas, sin modificarlas nunca hubiese funcionado ya que a las 2 horas daría Time Out.
3- Realizar un Job de “Stage” en el mismo Manager, esto creará una nueva carpeta: Program Files\CA\DSM\DMPrimer
4- Copiar la nueva carpeta DMPrimer con todo su contenido a la misma ubicación pero en el Scalability Server. Esto puede ser vía Copy/Paste, ó enviando algún medio (CD, Pendrive, etc.).
5- Una vez copiado, realizar pruebas: Crear una tarea desde el Manager, para instalar un Agente en la Subred de Destino, utilizando el Scalability Server recién instalado, y verán resultados positivos y con buena performance.
Espero les haya sido de utilidad!
Saludos…
Patricio Limeres
- Bookmark :
- Digg
- del.icio.us
- Stumbleupon
- Redit it
