Ir al contenido

Posts from the ‘Windows Server’ Category

23
Mar

Microsoft Exchange Server Vulnerabilities Mitigations – updated March 15, 2021

Para comprobar si el servidor es vulnerable se puede utilizar el siguiente
script del fabricante:
 
 
 
Adicionalmente, si quieren realizar una revisión en su red, pueden utilizar
este comando:
 
nmap -Pn -n –script=http-vuln-exchange,http-vuln-cve2021-26855 -p 443
 
que hace uso de los siguientes scripts:
 
 
 
Se recomienda la actualización de los sistemas afectados lo antes posible o
al menos, de forma temporal hasta poder realizar la actualización, no
permitir el acceso desde internet y aplicar las medidas de mitigación
indicadas por Microsoft:
 
 
 
Se han detectado múltiples actores maliciosos buscando y explotando estas
vulnerabilidades, los equipos que no hayan sido todavía parcheados podrían
considerarse comprometidos, por lo que se recomienda como mínimo realizar
un análisis en busca de webshells y otros indicadores de compromiso.
 
Explotando estas vulnerabilidades un atacante podría:
– Suplantar el servidor.
– Cargar archivos maliciosos en el sistema.
– Ejecutar código sin necesidad previa de autenticación.
– Robar información del servidor.
– Comprometer incluso el directorio activo mediante la generación de
«Golden tickets».
 
Sería recomendable recoger las evidencias forenses del servidor Exchange,
ponerlo en cuarentena, y si es posible, instalar uno nuevo desde un backup
confiable. Si existiesen evidencias de uso de alguna webshell, convendría
asimismo reconstruir por completo el directorio activo, forzando cambios de
contraseña para todos los usuarios.
 
Microsoft ha actualizado su herramienta MSERT que permite realizar escaneos
de seguridad para detectar la existencia de posibles webshells de
ProxyLogon y posteriormente eliminarlas. En el siguiente enlace dispone de
más información sobre la instalación y ejecución de la herramienta MSERT:
 
 
 
 
Disponen de más información sobre las vulnerabilidades e identificación de
evidencias en los siguientes enlaces:
 
 
 
 
 
 
 
Las actualizaciones para estas vulnerabilidades se encuentran disponibles
en:
 
 
 
To check if the server is vulnerable you can use the following manufacturer
script:
 
 
 
Additionally, if you want to perform a check on your network, you can use
this command:
 
nmap -Pn -n –script=http-vuln-exchange,http-vuln-cve2021-26855 -p 443
 
which makes use of the following scripts:
 
 
 
Multiple malicious actors have been detected looking for and exploiting
these vulnerabilities, computers that have not yet been patched could be
considered compromised, so it is recommended as a minimum to perform an
analysis in search of webshells and other indicators of compromise.
 
By exploiting these vulnerabilities an attacker could:
– Impersonate the server.
– Upload malicious files to the system.
– Execute code without prior authentication.
– Steal information From the server.
– Compromise even the active directory by generating “Golden tickets”.
 
It would be advisable to collect forensic evidence From the Exchange
server, quarantine it, and if possible, install a new one From a reliable
backup. If there is evidence of the use of a webshell, it would also be
advisable to completely rebuild the active directory, forcing password
changes for all users.
 
Microsoft has updated its MSERT tool that allows security scans to be
carried out to detect the existence of possible ProxyLogon webshells and
subsequently eliminate them. In the following link you have more
information about the installation and execution of the MSERT tool:
 
 
 
You have more information about vulnerabilities and identification of
evidence in the following links:
 
 
 
 
 
 
 
Updates for these vulnerabilities are available at:
 
 
 
19
Jun

Usando BgInfo

BgInfo es la típica utilidad de toda la vida (por cierto, cómo no, de Sysinternals) que nos puede servir para aclararnos un poco la vida, sobre todo si andamos en entornos grandes y desconocemos en qué servidor andamos logueándonos, o para hacer demos o cursos y que los alumnos vean cláramente en qué servidor estamos. Es una aplicación totalmente parametrizable en la que nos mostrará bastante información sobre el equipo donde se ejecuta. Podemos configurar que muestre en pantalla (combinado con el fondo de pantalla) el nombre del equipo, su dirección IP, sistema operativo, nivel de service pack, hora de arranque, tipo de CPU, puerta de enlace, máscara de red, servidores DNS, servidor DHCP, espacio libre en discos, discos duros disponibles, versión de Internet Explorer, dominio al que pertenece, controlador de dominio que le validó, Memoria RAM, tarjeta de red, velocidad de la red, tipo de equipo, usuario en uso, dominio logueado…

Bueno, podemos descargarlo gratuitamente de su web oficial (http://technet.microsoft.com/en-us/sysinternals/bb897557.aspx), lo ejecutamos en un equipo y ahí en tenemos las opciones para configurarlo, podemos seleccionar los campos que nos interesa que se vea, así como modificar cualquier necesidad, como el tamaño de la letra, idioma (manualmente)… si le damos a “Apply” se nos aplicará esa configuración en el equipo donde lo estemos ejecutando.

Y quedaría tipo esto, puede que no nos interese como está, podemos configurar lo que queremos que se vea y por supuesto mediante directivas del Directorio Activo para poder ejecutarlo en todos nuestros servidores o PC’s.

Estos son los parámetros que tenemos sobre el ejecutable bginfo.exe, pudiendo configurar el tiempo de espera a que se aplique el fondo (/timer), con ‘/popup’ en una ventana emergente, ‘/taskbar’ pondrá un icono en la barra de herramientas, con ‘/all’ conseguimos que se aplique a todos los usuarios logueados en el servidor, ‘/log’ nos generará logs, ‘/silent’ para que si hay errores no los muestre, ‘/rtf’ nos generará un archivo de ese formato con la info, y con ‘/nolicprompt’ evitaremos que nos pregunte por el acuerdo de licencia.

Así que abrimos Bginfo, nos configuramos la plantilla como queremos que sea, tipo letra, blablaba… y lo guardamos “File” > “Save As…”, en mi caso será algo parecido a:

—————————————

Nombre de equipo:

Hora de encendido:

CPU:

Memoria:

Disco duro:

Dirección IP:

Máscara de red:

Puerta de enlace:

Servidor DHCP:

Servidor DNS:

Dirección MAC:

Espacio libre:

Dominio:

Sistema Operativo:

Usuario:

—————————————–

Indicamos un nombre .bgi & “Guardar”,

Y ahora mediante un simple script lo podemos ejecutar en todos los equipos que nos interese, ejemplo:

\SERVIDORBgInfoBginfo.exe \SERVIDORBgInfobujarra.bgi /timer:0 /silent /nolicprompt

Y así quedaría nuestro fondo!

Obtenido de este enlace

18
Jun

Using a Reverse Proxy to Automatically Force External Lync Meeting Guests to Use Silverlight Client

https://lync.contoso.com/meet/username/EJHFSN and you are not a part of the Contoso organization and you do not have federation set up or do not allow automatic discovery of federated partners, it will fail with a useless numeric error code that means absolutely nothing.  Since the desktop client does not allow you log on anonymously, it will never fallback to guest logon, even if the meeting organizer has it enabled for the meeting. TechNet to the rescue!  All you have to do is append “sl=1” to the end of the query string of the URL, so that you visit https://lync.contoso.com/meet/username/EJHFSN?sl=1 and then it will force the Silverlight client, which will allow you to log on anonymously.  In this scenario, Lync meetings then behave basically like WebEx or GotoMeeting, where external participants need a browser plugin to connect to the meeting.  Perfect.  That’s exactly what I want. Again, one problem.  Imagine trying to get your entire staff to always remember to append that to the meeting link when they set up external meetings.  Despite best efforts, it’s just not going to happen.  Your CFO has better things to do and she will forget, because that is human nature.  And, really, this is Microsoft’s shortsightedness here.  You can read my comment at the TechNet article linked above.

Thanks for the “?sl=1” trick. That did the trick for me. But explaining this to my users is going to be a pain. Imagine me in the CFO’s office after months of extolling the virtues of Lync and how we even got rid of our WebEx subscription because, heck, Lync does meetings too! But suddenly, a meeting participant is also using Lync at his company but we have no federated relationship with each other, so when we click on each other’s meeting links it just fails with a terrible numerical error. “I thought this thing could replace WebEx,” the CFO bellows, scowling at me in disdain. “Oh, it can,” I reply, “just make sure you modify every meeting invitation so that the URL has ?sl=1 at the end of it!” Yea, that will go over well.

Thankfully, there is a workaround.  And due to the way Lync is designed, it’s really not difficult to set up. When you set up your Lync websites, it creates an internal and external site.  The external site by default uses the non-standard ports 8080 and 4443.  The Lync best practice is to use a Reverse Proxy or firewall port forwarding rules to send traffic destined for the normal web ports to the Lync alternate ports.  Your internal users, on the other hand, use ports 80 and 443 as normal, directly communicating with the Lync server. Reverse proxies can also be set up to modify URLs before the connection is sent to the backend.  This is known as URL Rewriting.  In this case, you want a URL rewrite rule that will modify connections to /meet/ such that ?sl=1 is always added to the end.  I found from trial and error that you get the best results by only modifying the /meet/ part of the above URL (assuming you are using Simple URLs like that).  So I set up my topology so that 8080 and 4443 were exposed directly to the outside so I have an option to bypass the reverse proxy once the connection is established.  This is all completely secure and transparent to the end user.  We’re not bypassing the firewall, just the reverse proxy’s URL rewriting when it is not needed. So the final topology looks like this.  (The Lync Front End is either your Edge server or your single server depending on the size of your deployment.) Lync Diagram From outside my firewall, ports 80, 443, 8080, and 4443 are all open.  If you connect to 80 or 443, you are sent to the reverse proxy.  If you go to 8080 or 4443, you are sent directly to Lync. To prepare Lync for this configuration, I first edited the topology so that the published ports are assigned the same as the internal (8080 and 4443) as this will allow us to bypass the reverse proxy when it is not needed. image Whenever you publish your topology, remember to rerun the Lync setup wizard. The reverse proxy can be easily created using IIS.  In fact, you can set it up on your Lync edge server if you want.  It depends on your workload.  For the purposes of this post, we’ll assume you are setting it up on the same server.   Note: Lync will stop any non-Lync website in IIS whenever you publish your topology and rerun setup, so be prepared for this! In order to configure the reverse proxy, you need to install the Application Request Routing and URL Rewrite extensions for IIS.  These both should already be installed if you are using your Lync server. Enable the Application Request Routing.  This is done at the server level.  Click on your IIS server in the IIS manager, double click Application Request Routing Cache, then click on Server Proxy Settings.  Check Enable proxy and keep everything else at defaults. image Create a new website.  Give it a folder path that is not shared with any other site (i.e., don’t reuse C:\Inetpub\wwwroot).  The bindings should be whatever the external IP address is mapped to through your firewall.  Bind HTTP and HTTPS on the default ports.  Make sure you use a different internal IP address than your Lync internal website so there isn’t a collision.  You don’t want internal users going through the reverse proxy. Go into the site’s URL Rewrite section and create a dummy rule.  We are going to overwrite this later, so it doesn’t matter what it is.  We just want to create a web.config that we can edit by hand. Edit the web.config “rules” section for the reverse proxy site.  Now here is where the fun begins.  We are going to modify any request that goes to /meet/ so that it has sl=1 at the end.  I created a rule for both HTTP and HTTPS since I am using default Lync ports (non-standard web ports).  There is also a condition that if the query string already contains sl=, it will not modify it.  Underneath the /meet/ rewrites are the default rules that just pass the request through unmodified to the correct ports.  Obviously, URLs, RegEx, ports, and so on, will all need to be modified to match your environment.

< rules>
    < rule name="ReverseProxyInboundRule1" stopProcessing="true">
        < match url="^meet/(.*)" />
        < conditions>
            < add input="{QUERY_STRING}" pattern="(.*)sl=(.*)" negate="true" />
            < add input="{CACHE_URL}" pattern="^(https)://" />
        conditions>
        < action type="Rewrite" url="{C:1}://lync.contoso.com:4443/{R:0}?sl=1&{QUERY_STRING}" appendQueryString="false" logRewrittenUrl="true" />
    rule>
    < rule name="ReverseProxyInboundRule2" stopProcessing="true">
        < match url="^meet/(.*)" />
        < conditions>
            < add input="{QUERY_STRING}" pattern="(.*)sl=(.*)" negate="true" />
            < add input="{CACHE_URL}" pattern="^(http)://" />
        conditions>
        < action type="Rewrite" url="{C:1}://lync.contoso.com:8080/{R:0}?sl=1&{QUERY_STRING}" appendQueryString="false" logRewrittenUrl="true" />
    rule>
    < rule name="ReverseProxyInboundRule3" stopProcessing="true">
        < match url="(.*)" />
        < conditions>
            < add input="{CACHE_URL}" pattern="^(https)://" />
        conditions>
        < action type="Rewrite" url="{C:1}://lync.contoso.com:4443/{R:1}" appendQueryString="true" logRewrittenUrl="true" />
    rule>
    < rule name="ReverseProxyInboundRule4" stopProcessing="true">
        < match url="(.*)" />
        < conditions>
            < add input="{CACHE_URL}" pattern="^(http)://" />
        conditions>
        < action type="Rewrite" url="{C:1}://lync.contoso.com:8080/{R:1}" appendQueryString="true" logRewrittenUrl="true" />
    rule>
rules>

If you attempt to connect to a meeting externally now, this is what happens.

  1. Browser initiates connection to https://lync.contoso.com/meet/username/EJHFSN.
  2. Reverse Proxy receives the request, adds sl=1 to the query string, and passes the request to the external Lync website at https://lync.contoso.com:4443/meet/username/EJHFSN?sl=1.
  3. Lync server replies and tells the browser to load the Silverlight Lync client which then attempts to connect directly to the lync web services (bypassing the Reverse Proxy) at https://pool1.lync.contoso.com:4443/Reach/Client/WebPages/ReachClient.aspx.
  4. The external user can join as an anonymous guest, or log on using the domain credentials of the organizer’s meeting, if they have that.  The desktop Lync client will never launch!

Hopefully in the future Microsoft will fix the desktop client to allow it to log on anonymously to external meetings and also give us a checkbox in the Lync Server Control Panel that allows us to force all external connections to the Silverlight client (for legacy organizations that might connect to ours).

Obtained from this link

 

18
Jun

Setting up a Reverse Proxy using IIS, URL Rewrite and ARR

Today there was a question in the IIS.net Forums asking how to expose two different Internet sites from another site making them look like if they were subdirectories in the main site.

So for example the goal was to have a site: www.site.com expose a www.site.com/company1  and a www.site.com/company2 and have the content from “www.company1.com” served for the first one and “www.company2.com” served in the second one. Furthermore we would like to have the responses cached in the server for performance reasons. The following image shows a simple diagram of this:

This sounds easy since its just about routing or proxying every single request to the correct servers, right? Wrong!!! If it only it was that easy. Turns out the most challenging thing is that in this case we are modifying the structure of the underlying URLs and the original layout in the servers which makes relative paths break and of course images, Stylesheets (css), javascripts and other resources are not shown correctly.

To try to clarify this, imagine that a user requests using his browser the page at http://www.site.com/company1/default.aspx, and so based on the specification above the request is proxied/routed to http://www.company1.com/default.aspx on the server-side. So far so good, however, imagine that the markup returned by this HTML turns out to have an image tag like “<img src=/some-image.png />”, well the problem is that now the browser will resolve that relative path using the base path on the original request he made which was http://www.site.com/company1/default.aspx resulting in a request for the image at http://www.site.com/some-image.png instead of the right “company1” folder that would be http://www.site.com/company1/some-image.png .

Do you see it? Basically the problem is that any relative path or for that matter absolute paths as well need to be translated to the new URL structure imposed by the original goal.

So how do we do it then?

Enter URL Rewrite 2.0 and Application Request Routing

URL Rewrite 2.0 includes the ability to rewrite the content of a response as it is getting served back to the client which will allow us to rewrite those links without having to touch the actual application.

Software Required:

Steps

  1. The first thing you need to do is enable Proxy support in ARR.
    1. To do that just launch IIS Manager and click the server node in the tree view.
    2. Double click the “Application Request Routing Cache” icon
    3. Select the “Server Proxy Settings…” task in the Actions panel
    4. And Make sure that “Enable Proxy” checkbox is marked. What this will do is allow any request in the server that is rewritten to a server that is not the local machine will be routed to the right place automatically without any further configuration.
  2. Configure URL Rewrite to route the right folders and their requests to the right site. But rather than bothering you with UI steps I will show you the configuration and then explain step by step what each piece is doing.
  3. Note that for this post I will only take care of Company1, but you can imagine the same steps apply for Company2, and to test this you can just save the configuration file below as web.config and save it in your inetpub\wwwroot\  or in any other site root and you can test it.
<?xml version=”1.0″ encoding=”UTF-8″?>
<configuration>
<system.webServer>
<rewrite>
<rules>
<rule name=”Route the requests for Company1″ stopProcessing=”true”>
<match url=”^company1/(.*)” />
<
conditions>
<add input=”{CACHE_URL}” pattern=”^(https?)://” />
</
conditions>
<action type=”Rewrite” url=”{C:1}://www.company1.com/{R:1}” />
<
serverVariables>
<set name=”HTTP_ACCEPT_ENCODING” value=”” />
</
serverVariables>
</rule>
</rules>
<outboundRules>
<rule name=”ReverseProxyOutboundRule1″ preCondition=”ResponseIsHtml1″>
<match filterByTags=”A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script” pattern=”^http(s)?://www.company1.com/(.*)” />
<
action type=”Rewrite” value=”/company1/{R:2}” />
</
rule>
<rule name=”RewriteRelativePaths” preCondition=”ResponseIsHtml1″>
<match filterByTags=”A, Area, Base, Form, Frame, Head, IFrame, Img, Input, Link, Script” pattern=”^/(.*)” negate=”false” />
<
action type=”Rewrite” value=”/company1/{R:1}” />
</
rule>
<preConditions>
<preCondition name=”ResponseIsHtml1″>
<add input=”{RESPONSE_CONTENT_TYPE}” pattern=”^text/html” />
</
preCondition>
</preConditions>
</outboundRules>
</rewrite>
</system.webServer>
</configuration>

Setup the Routing

                <rule name=”Route the requests for Company1″ stopProcessing=”true”>
<match url=”^company1/(.*)” />
<
conditions>
<add input=”{CACHE_URL}” pattern=”^(https?)://” />
</
conditions>
<action type=”Rewrite” url=”{C:1}://www.company1.com/{R:1}” />
<
serverVariables>
<set name=”HTTP_ACCEPT_ENCODING” value=”” />
</
serverVariables>
</rule>

The first rule is an inbound rewrite rule that basically captures all the requests to the root folder /company1/*, so if using Default Web Site, anything going to http://localhost/company1/* will be matched by this rule and it will rewrite it to www.company1.com respecting the HTTP vs HTTPS traffic.

One thing to highlight which is what took me a bit of time is the “serverVariables” entry in that rule that basically is overwriting the Accept-Encoding header, the reason I do this is because if you do not remove that header then the response will likely be compressed (Gzip or deflate) and Output Rewriting is not supported on that case, and you will end up with an error message like:

HTTP Error 500.52 – URL Rewrite Module Error.
Outbound rewrite rules cannot be applied when the content of the HTTP response is encoded (“gzip”).

Also note that to be able to use this feature for security reasons you need to explicitly enable this by allowing the server variable. See enabling server variables here.

 

Outbound Rewriting to fix the Links

The last two rules just rewrite the links and scripts and other resources so that the URLs are translated to the right structure. The first one rewrites absolute paths, and the last one rewrites the relative paths. Note that if you use relative paths using “..” this will not work, but you can easily fix the rule above, I was too lazy to do that and since I never use those when I create a site it works for me 🙂

Setting up Caching for ARR

A huge added value of using ARR is that now we can with a couple of clicks enable disk caching so that the requests are cached locally in the www.site.com, so that not every single request ends up paying the price to go to the backend servers.

  1. To do that just launch IIS Manager and click the server node in the tree view.
  2. Double click the “Application Request Routing Cache” icon
  3. Select the “Add Drive…” task in the Actions panel.
  4. Specify a directory where you want to keep your cache. Note that this can be any subfolder in your system.
  5. Make sure that “Enable Disk Cache” checkbox is marked in the Server Proxy Settings mentioned above.

As easy as that now you will see caching working and your site will act as a container of other servers in the internet. Pretty cool hah! 🙂

So in this post we saw how with literally few lines of XML, URL Rewrite and ARR we were able to enable a proxy/routing scenario with the ability to rewrite links and furthermore with caching support.

Obtained from this link

18
Jun

iSCSI Best Practices (Microsoft, EMC, VMware) – Summarized

This document summarizes the best practices of iSCSI usage as described in the following guides from MS, EMC, and VMware.

MS & iSCSI –

Exchange:

–         Microsoft Exchange Server can store its program files, mailboxes, public folders, logs and other data on iSCSI disk volumes in both cluster and non cluster configurations.

–         Keep the Exchange disks in a separate pool on the array.

 

SQL Server – Microsoft SQL Server can store its program files, logs and other data on iSCSI disk volumes in both cluster and non cluster configurations

 

NOTE: iSCSI initiator does not support Dynamic disk volumes and NIC teaming.

 

iSNS – Microsoft iSNS Server is a Microsoft Windows service that processes iSNS registrations, de-registrations, and queries via TCP/IP from iSNS clients, and also maintains a database of these registrations. iSNS servers can be clustered.

 

iSCSI Boot:

–         Windows can be booted off of an iSCSI disk however; the iSCSI boot initiator will disable all kernel mode code paging. Additionally the pagefile must not be located on an iSCSI disk.

–         Windows Server 2003 can be booted from a SAN using either an FC HBA or an iSCSI HBA

iSCSI Best Practices:

–         Deploy on fast networks – at least a GigE or better network

–         Ensure physical security

–         Use strong passwords for all accounts

–         Use CHAP authentication because that ensures each host has its own password. Mutual CHAP authentication is even better. Use One Way or Mutual CHAP

–         Use iSNS for discovery

–         Segregate iSCSI SANs from LAN traffic

–         Use IPsec

–         Use Access Control  or LUN masking

Networking Best Practices for iSCSI:

–         Use non blocking switches and set the negotiated speed on the switches.

–         Disable unicast storm control on iSCSI ports.  Most switches have unicast storm control disabled by default.

–         Enable Flow Control on network switches and adapters; flow control ensures a receiver can make the sender pace its speed and is important in avoiding data loss.

–         Ensure spanning tree algorithm for detecting loops is turned off on the ports used for iSCSI traffic.

–         Segregate SAN and LAN traffic.  iSCSI SAN interfaces should be separated from other corporate network traffic (LAN).   Servers should use dedicated NICs for SAN traffic.  Deploying iSCSI disks on a separate network helps to minimize network congestion and latency.  Additionally, iSCSI volumes are more secure when… Segregate SAN & LAN traffic can be separated using port based VLANs or physically separate networks.

–         Configure additional Paths for High Availability; use either Microsoft MPIO or MCS (multiple connections per session) with additional NICs in the server to create additional connections to the iSCSI storage array through redundant Ethernet switch fabrics.

–         Unbind File and Print Sharing from the iSCSI NIC – on the NICs which connect only to the iSCSI SAN, unbind File and Print Sharing.

–         Use Gigabit Ethernet connections for high speed access to storage.  Congested or lower speed networks can cause latency issues that disrupt access to iSCSI storage and applications running on iSCSI devices.  In many cases, a properly designed IP-SAN can deliver better performance than internal disk drives.

–          iSCSI is suitable for WAN and lower speed implementations including replication where latency and bandwidth are not a concern.

–         Use Server class NICs.  It is recommended to use NICs which are designed for enterprise networking and storage applications.

–         Use CAT6 rated cables for Gigabit Network Infrastructures.  For 10Gigabit implementations, Cat-6a or Cat-7 cabling is usually required for use with distances over 55 meters.

–         Use Jumbo Frames if supported in your network infrastructure. Jumbo Frames can be used to allow more data to be transferred with each Ethernet transaction and reduce the number of frames.  This larger frame size reduces the overhead on both your servers and iSCSI targets. For end to end support, each device in the network needs to support Jumbo frames including the NIC and Ethernet switches.

Redundancy & Load Balancing:

There are two technologies supported with the MS iSCSI software initiator to enable redundancy and load balancing:

–         Multiple connections per session (MCS) – Multiple connections per session (MCS) support is defined in the iSCSI RFC to allow multiple TCP/IP connections from the initiator to the target for

-the same iSCSI session. This is iSCSI Protocol specific. In this way I/O can be sent over either TCP/IP connection to the target. If one connection fails another connection can continue processing I/O without interruption to the application. Note that not all iSCSI targets support MCS.

–         Microsoft MPIO support

 

There are a number of things to consider when choosing to use MCS or Microsoft MPIO for multipathing.

–         If your configuration uses hardware iSCSI HBA then Microsoft MPIO should be used.

–         If your target does not support MCS then Microsoft MPIO should be used.  Most iSCSI target arrays support Microsoft MPIO.

–         If your target does support MCS and you are using the Microsoft software initiator driver then MCS is the best option. There may be some exceptions where you desire a consistent management interface among multipathing solutions and already have other Microsoft MPIO solutions installed that may make Microsoft MPIO an alternate choice in this configuration.

–         If you need to specify different load balance policies for different LUNs then Microsoft MPIO should be used.

–         If you are using Windows XP or Windows Vista, MCS is the only option since Microsoft MPIO is only available with Windows Server SKUS.

 

NOTE: There does not exist a mechanism within the iSCSI protocol to determine whether a target is active/active or active/passive.

 

Load Balance Policies:

 

–         Fail Over Only: No load balancing is performed. There is a single active path and the rest of the paths are standby paths. The active path is used for sending all I/O. If the active path fails then one of the standby paths is used.   When the formally active path is reconnected it will become active and the standby path that was activated would return to standby.

–         Round Robin: All paths are active paths and they will be used for sending I/O in a round robin fashion.

–         Round Robin with a subset of paths: A set of paths are configured as active and a set of paths are configured as standby. I/O is sent in a round robin fashion over the active paths. If all of the active paths fail then one of the standby paths is used. If any of the formerly active paths become available again then the formerly active paths are used and the standby path that was activated becomes a standby path again.

–         Weighted Path: Each path is assigned a weight and I/O will be sent on the path with the lowest weight. If the path with the lowest weight fails then the path with the next lowest weight will be used.

–         Least Queue Depth: This is only supported by MCS. The path that has the fewest number of requests queued is the one where the I/O is sent.

 

NOTE: Windows does not support disks that have been formatted to anything other than a 512byte block size. Block size refers to the low level formatting of the disk and not the cluster or allocation size used by NTFS. Be aware that using a disk with a block size larger than 512 bytes will cause applications not to function correctly.  You should check with your iSCSI target manufacture to ensure that their default block size is set to 512 bytes or problems will likely occur.

EMC & iSCSI –

A Look At EMC iSCSI Storage Systems (CLARiiON):

–         EMC supports Microsoft Windows® 2000 and Microsoft Windows Server™ 2003 servers that run the native iSCSI Microsoft-certified driver for NICs. Supported devices include both onboard NICs in Microsoft-certified servers and PCI-based NICs that are Microsoft-certified.

–         EMC supports Microsoft Windows 2000 and Microsoft Windows Server 2003 servers that use QLogic QLA4010 (optical) or QLA4010C (copper) HBAs and drivers.

–         You cannot mix NICs and HBAs in the same server, even if they are connected to different storage systems.

–         You must not connect a single server to both a CLARiiON® Fiber Channel storage system and an iSCSI storage system.

–         Servers with HBAs and servers with NICs can connect to the same storage system.

–         A single server can connect to CLARiiON CX-Series iSCSI storage systems and Symmetrix® iSCSI storage systems when a common network configuration, common failover software, and common driver support for both platforms exists.

–         A single server can connect to CLARiiON AX-Series iSCSI storage systems, and through IP-to-FC switches, to CLARiiON AX-Series Fibre Channel storage systems when a common network configuration, common failover software, and common driver support for both platforms exists.

–         A single server can connect to CLARiiON CX-Series iSCSI storage systems, and through IP-to-FC switches, to CLARiiON CX-Series Fibre Channel storage systems when a common network configuration, common failover software, and common driver support for both platforms exists.

–         Using the CLARiiON Open Systems Configuration Guide (OSGC) definition of fan-in (server to storage system), you can connect a server to a maximum of four storage systems.

–         Using the EMC Support Matrix (ESM) definition of fan-in (storage-system ports visible to a single initiator), you can connect an initiator to a maximum of 16 storage-system ports, but no more than four storage systems. The connection to the storage system must be 1-gigabit copper (RJ45).

–         EMC does not support 10/100 NIC connections that are connected directly to the storage system, except for those connected to the management ports.

–         Direct connections must be either with or 10/100/1000 NICs (operating at 1 gigabit) or QLA4010C HBAs. Ethernet crossover cables must be used with NICs to direct the server to the storage system.

–         Using the OSCG and ESM definitions of fan-out (initiators per SP port), you can connect a maximum of 128 initiators to a CX-Series iSCSI SP port.

–         If your service will not use iSNS, you must configure target storage-system addresses manually on the server initiators.

–         You must configure server names and passwords manually on the iSCSI storage system. If you want authentication, you must use CHAP (Challenge Handshake Authentication Protocol).

–         A CX-Series iSCSI storage system has two front-end (data) iSCSI ports per storage processor.

–         EMC supports up to four HBAs or four NICs in one server that connects one CX-Series iSCSI storage system.

–         Currently you cannot boot a Windows system using an iSCSI disk volume that the Microsoft iSCSI Software Initiator provides. The only currently supported method for booting a Windows system using an iSCSI disk volume is with a supported HBA.

–         Microsoft iSCSI Software Initiator does not support dynamic disks.

–         Microsoft iSCSI Initiator version 1.05a supports iSCSI Windows Server 2003 Cluster environments with a maximum of two nodes.

–         The Microsoft iSCSI Initiator default configuration ignores multiple NICs on the same subnet. When multiple NICS are on the same subnet, use the Advanced button in the Log On to Target dialog box of the Microsoft iSCSI Software Initiator UI to associate a specific NIC with a specific SP port.

–         Do not use Microsoft iSCSI Software Initiator to control the QLogic HBAs. QLogic’s SANsurfer utility is the only supported interface to HBAs.

–         A CX-Series iSCSI storage system does not support Microsoft iSCSI Software Initiator version 1.05a configured for MPIO, CRC/Checksum Data digest, or Header digest.

–         Supported Configurations:

  • Servers’ with Single NIC/HBA & 1 Subnet
  • Servers’ with Multiple NICs/HBAs & 1 Subnet
  • Servers’ with Multiple NICs/HBAs & Multiple Subnets
  • Servers with Multiple NICs/HBAs & Direct Connections
  • Multiple NICs/HBAs to Multiple Subnets, Routed or Independent (Including Direct Connections) is supported.

 

NOTE: A high hop count can also contribute to performance degradation.  Performance anomalies can also result for reasons associated with the various inherent TCP/IP flow control algorithms such as delayed ACK, slow start, and Nagle.

 

NOTE: You can use an iSCSI analyzer to perform protocol analysis of traffic flowing into and out of any suspect port on the storage system.

 

NOTE: You must install the Microsoft iSCSI Software Initiator because the Navisphere Server Utility uses it to configure iSCSI connections.  You must install the Initiator Service option of the Microsoft iSCSI Software Initiator because the QLogic driver requires it.

 

NOTE: PowerPath iSCSI is no longer available for CX3 series and CX series storage systems. PowerPath 4.5.1 or earlier Do not select Microsoft MPIO Multipathing Support for iSCSI. Do not select Microsoft MPIO Multipathing Support for iSCSI or Software Initiator.

 

NOTE: You can improve the performance of any NICs that will be used primarily for iSCSI traffic rather than general network traffic by changing the network settings so that NICs immediately acknowledge incoming TCP segments. If you are running a version of the Navisphere Server Utility that is earlier than 6.24.1.4.0, you need to manually modify the TCP/IP registry settings, as described below, to improve performance. If you are running Navisphere Server Utility version 6.24.1.4.0 or later, the system will prompt you to change these settings when you configure the network parameters for your NICs (set up iSCSI connections).

 

NOTE: When you remove an iSCSI target, the specified target and all other targets on the storage system will be removed. If you want to remove a specific target but not all targets on the storage system, you must use the Microsoft Software Initiator.

VMware & iSCSI –

–         VI3 uses single connection for a session

–         At present, the VMware software initiator does not support jumbo frames. And until 10 gigabit Ethernet is supported by the VMware software initiator, the performance benefit of using jumbo frames would be minimal.

–         The software-initiator iSCSI implementation leverages the VMkernel to perform the SCSI to IP translation and does require extra CPU cycles to perform this work. As a result, software iSCSI can reduce overall server performance when CPUs are under heavy load.

–         Don’t use VMware Consolidated Backup over iSCSI

–         Best practice is to have a dedicated LAN for iSCSI traffic and not share the network with other network traffic.  It is also best practice not to oversubscribe the dedicated LAN.

–         VMkernel has a single routing table for all its VMkernel Ethernet interfaces

–         Make sure both the VMotion and IP Storage network and the service console port connection have appropriate IP addresses and are routed properly to the array.

–         The VMware VMkernel IP networking stack has been extended to handle the following functions:

  • iSCSI as a virtual machine datastore (new in ESX Server 3)
  • NFS as a virtual machine datastore (new in ESX Server 3)
  • NFS for the direct mounting of ISO files, which are presented as CD-ROMs to virtual machines
  • Migration with Vmotion

–         Make sure both the VMotion and IP Storage network and the service console port connection have appropriate IP addresses and are routed properly to the array.

–         The IP address that you assign to the service console during installation must be different from the IP address that you assign to VMkernel’s IP stack from the Configuration > Networking tab of the Virtual Infrastructure Client. The NFS and iSCSI functions must be configured together. They always share the same IP address, gateway, netmask, and other parameters. They are connected to the same virtual switch and, therefore, to the same physical Ethernet adapter. Before configuring software iSCSI for the ESX Server host, you need to open a firewall port.

–         Metadata Updates – A VMFS holds files, directories, symbolic links, RDMs, and so on, along with corresponding metadata for these objects. Metadata is accessed each time the attributes of a file are accessed or modified. These operations include, but are not limited to:

  • Creating, growing, or locking a file.
  • Changing a file’s attributes.
  • Powering a virtual machine on or off.

CAUTION After you create a new VMFS volume or extend an existing VMFS volume, you must rescan the SAN storage from all ESX Server hosts that could see that particular volume (LUN). If this is not done, the shared volume might become invisible to some of those hosts.

–         Levels of Indirection – If you’re used to working with traditional SANs, the levels of indirection can initially be confusing.

  • You cannot directly access the virtual machine operating system that uses the storage. With traditional tools, you can monitor only the VMware ESX Server operating system (but not the virtual machine operating system). You use the VI Client to monitor virtual machines.
  • Each virtual machine is, by default, configured with one virtual hard disk and one virtual SCSI controller during installation. You can modify the SCSI controller type and SCSI bus sharing characteristics by using the VI Client to edit the virtual machine settings. You can also add hard disks to your virtual machine.
  • The HBA visible to the SAN administration tools is part of the ESX Server system, not the virtual machine.
  • Your ESX Server system performs multipathing for you. Multipathing software (such as PowerPath) in the virtual machine is not supported (and not required).

–         Choosing Larger or Smaller LUNs:

Plan how to set up storage for your ESX Server systems before you perform installation.

  • One large LUN or many LUNs with a single VMFS volume spanning all LUNs: You might want fewer, larger LUNs for the following reasons:
    • More flexibility to create virtual machines without asking the SAN administrator for more space.
    • More flexibility for resizing virtual disks, doing snapshots, and so on
    • Fewer LUNs to identify and manage

 

  • Many LUNs with one VMFS volume on each LUN:  You might want more, smaller LUNs for the following reasons:
    • Less contention on each VMFS because of locking and SCSI reservation issues.
    • Different applications might need different RAID characteristics.
    • More flexibility (the multipathing policy and disk shares are set per LUN).

 

NOTE: You can divide your datacenter into servers that are best configured with fewer, larger LUNs and other servers that use more, smaller LUNs.

 

NOTE: You can boot from a SAN only with ESX Server 3 and with hardware iSCSI.

 

NOTE: If you plan to use NIC teaming to increase the availability of your network access to the iSCSI storage array, you must turn off port security on the switch for the two ports on which the virtual IP address is shared. The purpose of this port security setting is to prevent spoofing of IP addresses. Thus many network administrators enable this setting. However, if you do not change it, the port security setting prevents failover of the virtual IP from one switch port to another and NIC teaming cannot fail over from one path to another. For most LAN switches, the port security is enabled on a port level and thus can be set on or off for each port.

 

NOTE: SCSI reservations are held during metadata updates to the VMFS volume. ESX Server uses short‐lived SCSI reservations as part of its distributed locking protocol.

 

NOTE: VMware recommends that you load balance virtual machines over servers, CPU, and storage. Run a mix of virtual machines on each server so that not all experience high demand in the same area at the same time.

 

NOTE: Whether a virtual machine can run management software successfully depends on the storage system in question.

Obtained from thid link

17
Jun

El almacenamiento en Hyper-V (v 1.1)

Introducción

Continuando con la serie de artículos que empecé con el articulo sobre como escoger un host equilibrado, los procesadores y la memoria, hoy os hablare del almacenamiento y la idea es cerrar esta serie con un articulo sobre redes.

En un entorno no virtualizado la carga del almacenamiento se distribuye entre la SAN y el almacenamiento local de los servidores, mientras que en un entorno virtualizado lo mas probable es que la SAN absorba prácticamente toda la carga.

Desgraciadamente la virtualización no siempre va acompañada de un análisis adecuado y gracias a la potencia de las tecnologías de hoy en día podemos tener la sensación de que la virtualización es un saco que lo aguanta todo, que no hay que tener cuidado, sin embargo mas tarde o mas temprano tendremos que poner la atención en diferentes elementos de nuestra plataforma si es que quieres que esta pueda seguir asumiendo carga y mantener el rendimiento dentro de unos parámetros aceptables.

La verdad es que con mucho considero el almacenamiento el aspecto mas complicado de la virtualización, la cantidad de elementos que intervienen es amplísima empezando por las cabinas en constante evolución gracias a un mercado súper-competitivo en el que como dice mi compañero David Cervigón cuyo conocimiento sobre estos temas es mas que envidiable “en el almacenamiento todo esta por hacer”.

En cuanto al almacenamiento en la virtualización existen dos corrientes de pensamiento básicas:

1) Estandarizar una configuración determinada, llenarla mientras aguante, escalar cuando sea necesario para mantener un rendimiento aceptable

Contras:

-Hay cargas que es complicado virtualizar de esta forma, especialmente las que hagan uso intensivo de disco.

-Las implicaciones terminan apareciendo desde el punto de vista de backups/recuperaciones, rendimiento no predecible, etc.

-Para mitigar en cierta forma el problema se puede terminar moviendo frecuentemente los discos de las VMs lo que al final es menos eficiente que pensar en ello desde el principio

-A medio o largo plazo se termina teniendo que replantearse el almacenamiento o comprar sistemas mas potentes que nos den margen durante mas tiempo

PROS:

-Es un sistema simple y rápido a primera vista

-Puede funcionar sin problemas en muchos entornos cuyas infraestructuras de almacenamiento están sobredimensionadas.

2) Estandarizar las configuraciones apropiadas para obtener desde el principio un rendimiento predecible y optimizado, lo que requiere conocer y analizar diferentes aspectos del almacenamiento

Contras:

Requiere algo mas de tiempo y conocimientos para el análisis

-Puede suponer un mayor numero de volúmenes y espacio consumido al principio de los proyectos

PROS:

-Una vez realizado el trabajo inicial es fácil de mantener

-Evita problemas con el tiempo siendo una arquitectura predecible

-El rendimiento general es mejor y sostenible

Si me preguntarais por mi opinión personal os diría que en general soy partidario de la segunda opción,.

Dado que este tema es difícil de entender solo escuchando una sesión técnica cosa que hago muy a menudo, he decido escribir este post de forma que pueda servirme de apoyo al explicarlo y esperando que os sea de utilidad a todos los que terminéis aquí por alguna razón.

Aviso: Cada cabina es un mundo y el numero de combinaciones entre discos, arquitecturas, conectividad y parametrización es infinita así que todas las cifras que muestro en este articulo son para los sistemas específicos en los que he realizado las pruebas o de aquellos cuya información he visto reflejada en diferentes pruebas realizadas por Microsoft o los fabricantes, cada entorno insisto tendrá sus propias cifras. En este articulo hablaremos también de como averiguar las cifras actuales de tu entorno y como realizar mediciones del impacto de los cambios que hagas.

Que vamos a ver en este articulo:

  • Conceptos generales sobre almacenamiento
    • Patrones de uso
    • El tipo de interface de disco
    • El Disco
    • Las LUNs y las cabinas
    • El RAID y el tamaño de banda
    • Formateando nuestros discos (GPT vs MBR, el “unit allocation size”)
    • Evitando problemas de alineamiento
    • Conoce tu hardware
    • Aprende a probar el rendimiento del almacenamiento
  • El almacenamiento en Hyper-V
    • Haciendo las cosas bien: la importancia del análisis
    • De físico a virtual
    • Encriptación y compresión
    • Arranque desde SAN
    • ¿Que dispositivos de almacenamiento puedo usar con Hyper-V?
    • MPIO
    • Usando iSCSI
    • Tipos de discos en las maquinas virtuales
    • Todo lo que tienes que saber sobre CSV y otros tipos de discos en los hosts
    • Diseñar los discos duros virtuales de las VM
    • Los limites de Hyper-V para hosts y VMs
    • ¿Necesitas aun mas rendimiento?

 

Conceptos generales sobre el almacenamiento

Para que podáis sacar el mayor partido del articulo tengo que asegurarme de que conocéis algunos conceptos fundamentales del almacenamiento que muchas veces son pasados por alto, conocerlos os será igual de útil en entornos físicos que virtuales incluso con diferentes fabricantes de virtualización.

Patrones de uso

Dentro de un servidor existen a parte del sistema operativo aquellos servicios responsabilidad del servidor.

Cada uno de estos servicios hace un uso diferente del disco duro, de esta forma no es lo mismo el uso de un disco duro de un servidor de base de datos de un ERP que de un servidor de ficheros.

En base a estos diferentes tipos de uso podemos hablar de unos patrones que están formados por los siguientes elementos:

Escritura/lectura: Por ejemplo un servidor de ficheros suele ser un 80% lectura contra un 20% escritura, mientras que un servidor web generalmente será un 100% lectura.

Secuencial/aleatorio: Un servidor de streaming de video será 100% secuencial y normalmente todos los servidores que muevan grandes volúmenes de datos en bloque tenderán a ser secuenciales y los datos se leerán o escribirán de seguido, por ejemplo una base de datos será en muchas ocasiones aleatoria pues los datos estarán muy dispersos.

Tamaño de la operación: Por ejemplo muchas veces un sistema determinado como por ejemplo Exchange o SQL Server suelen siempre leer del disco bloques del mismo tamaño por ejemplo dependiendo del producto 8KB,32KB o 64KB, mientras que un servidor de ficheros solicitara bloques de muy diferentes tamaños donde a lo mejor las solicitudes de bloques de 64KB suponen el 10% de las operaciones y las de 16KB el 4% y así.

A cada operación de lectura o escritura a realizar la llamamos IO, las IO por segundo serán las IOPS.

En este articulo vamos a ver muchos parámetros que afectan al rendimiento del almacenamiento el primer paso para tomar buenas decisiones es entender el patrón de uso de tus servidores lo que puedes empezar haciendo con el performance monitor y tantas otras herramientas.

La siguiente tabla muestra ejemplos de algunos patrones estándar:

El tipo de interface

Es cierto que iSCSI esta creciendo mucho y creo que todos estamos muy contentos con iSCSI, solo tengo que decir que cuando vayamos a utilizar iSCSI tenemos que hacerlo de forma adecuada aislando y dimensionando adecuadamente las redes de iSCSI, utilizando Jumbo frames y otras optimizaciones que nos harán sacar el máximo partido de esta tecnología que nos aporta tanta flexibilidad.

Es muy común encontrarnos con fibra óptica (FC) que también es estupenda.

Para vuestro conocimiento aquí tenéis una tabla con el rendimiento teórico de diferentes tipos de arquitectura de almacenamiento.

Arquitectura Rendimiento (Máximo Teórico – Megabyte/sec)
iSCSI (Gigabit Ethernet) 125 MB/s
Fibre Channel (2 GFC) 212.5 MB/s
SATA (SATA II) 300 MB/s
SCSI (U320) 320 MB/s
SAS 375 MB/s
Fibre Channel (4 GFC) 425 MB/s

 

Hoy en día empezamos también a ver interfaces de 10 Gigabit que usados para iSCSI o FCOE pueden dar rendimientos fantásticos como veis en el siguiente grafico:

El disco

Muchas SAN nos permiten elegir diferentes tipos de discos y luego poder crear diferentes grupos de discos con ellos.

Las ultimas cabinas de algunos fabricantes incluso son capaces de juntar en el mismo grupo diferentes tipos de discos y mover los bloques de datos a aquellos discos donde mejor estén, teniendo en cuenta la frecuencia de uso y patrón del mismo.

A la hora de escoger los discos estaremos impactando dos cosas principalmente; coste y rendimiento.

Un aspecto determinante a la hora de escoger el disco son las revoluciones del mismo (RPM), las velocidades mas comunes en entorno de servidores son 7200, 10000 y 15000RPM.

Las revoluciones tienen además otras connotaciones en los discos como podéis ver en las siguientes imágenes, esto implica por tanto que no solo los discos giran mas rápido sino que los platos son mas pequeños y las agujas se tienen que desplazar menos.

El siguiente grafico muestra el numero de operaciones en disco aleatorias de 8K que he obtenido en diferentes discos según sus revoluciones (en este grafico mas es mejor).

Si a alguno os intriga cuantas IOPS tiene un disco de estado solido (SSD) podríamos decir que hay quien las sitúa entorno a las 6000!!

El siguiente grafico os muestra la diferencia entre discos de 15K RPM y 10K RPM de tipo SCSI en el escenario concreto de lecturas secuenciales de bloques de 8K, añado también un disco SATA de 10K para que veáis también el impacto que tiene SATA vs SCSI. (En este grafico mayor latencia es peor mientras que mas lecturas por segundo es mejor).

Esto no significa que todos los discos tengan que ser de 15K por que son mejores, simplemente que debemos entender la diferencia y en ocasiones elegir que conviene mas.

Las LUNs y las cabinas

Una LUN (Logical Unit Number) es un disco virtual proporcionado por la SAN y que presentamos a uno o mas hosts.

Fijaros que digo “virtual” esto es así porque la LUN no tiene por que representar un disco físico conectado a la cabina, normalmente todas las cabinas reúnen grandes grupos de discos físicos incluso de diferente configuración y sobre estos generan estas unidades repartiendo los bloques que las componen entre los diferentes discos físicos, de esta forma se obtiene mejor rendimiento.

Algunas SAN aportan funcionalidades adicionales, como crear las LUN usando un modo que se llama “thin”, lo que hace que la unidad vaya ocupando espacio en la SAN a medida que se vaya usando, este tipo de LUNs están creciendo en popularidad, sin embargo os tengo que decir que dependiendo de la cabina esto puede suponer una pequeña penalización y os sugiero que establezcáis un baseline comparando el rendimiento de la misma carga con una LUN “thin” y otra normal de forma que conozcáis el impacto exacto en vuestro entorno a la hora de tomar vuestras decisiones.

Otra funcionalidad de algunas SAN muy interesante es la llamada deduplicación con la cual la SAN ahorra el espacio de los bloques que se encuentren almacenados en la SAN mas de una vez, como esto se realiza a nivel de bloque los ahorros pueden ser muy importantes ya que por ejemplo en un entorno VDI la mayor parte de los discos duros virtuales puede ser prácticamente igual. Una vez mas con esta funcionalidad recomiendo hablar con el fabricante para entender las buenas practicas que recomiende y tener especial cuidado con el impacto que esto tiene en la CPU y resto de recursos de nuestra cabina.

A medida que aumentamos discos en un grupo de discos de las SAN también aumentamos el numero de operaciones de entrada y salida (IOPS) que nos da la cabina.

El siguiente grafico muestra los datos para un fabricante determinado.

Las cabinas también avanzan a un ritmo tremendo así con cada versión y modelo los fabricantes añaden mas cache, mejores firmwares y elementos que aumentan el rendimiento, por eso elegir la cabina y comparar varias tiene mucha importancia.

El siguiente grafico muestra la diferencia entre dos cabinas del mismo fabricante pero de diferente gama, con discos con las mismas RPM e igual numero de discos (240)

El RAID

Otra aspecto a comentar es el nivel de RAID, como sabéis RAID tiene diferentes niveles, 0,1,2,3,4,5,6,5E, 6E, 0+1, 1+0, 30, 100, 50 y un buen numero mas de combinaciones y especificaciones propietarias, siendo los mas comunes de encontrar los raid 1 y 5 y limitando cada cabina que RAIDs puedes configurar.

RAID 1: Los datos se escriben en dos discos, generalmente mejora lecturas dado que puedes leer de dos sitios pero degrada la escritura por la misma razón aunque el rendimiento de escrituras pequeñas es muy bueno.

Dado que por cada disco perdemos otro es un RAID muy caro

RAID 5: Buen rendimiento en lecturas pero malo en pequeñas escrituras, es mas barato por que pierdes menos discos que con RAID 1, en caso de fallo de un disco todo el rendimiento se ve afectado.

Fijaros en que puntualizo el aspecto de escrituras pequeñas dado que tiene mucha importancia de forma especial en discos que por ejemplo dediquéis a logs, en general las escrituras se ven perjudicadas por el RAID, el siguiente grafico muestra la penalización en discos de 15K RPM:

Los RAID tienen repercusiones tanto a nivel de tolerancia a fallos permitiendo al sistema sobrevivir a la perdida de algún disco que componga el RAID como a nivel de rendimiento, cada nivel tiene ventajas y desventajas, unos favorecen las lecturas otros las escrituras, unos las cargas secuenciales y otros las aleatorias incluso se puede hablar de impacto en CPU o diferencias según la cantidad de datos que se quieran mover en las operaciones.

Muchas cabinas implementan siempre cierto nivel de RAID a bajo nivel y normalmente esto no se puede elegir, por otra parte algunas cabinas ya no dejan elegir el nivel de RAID individual para las LUN, deciros que ese uso de cierto nivel de RAID a bajo nivel en muchas cabinas no esta reñido con que la LUN tenga además un nivel de RAID adicional.

Es cierto que las caches de las controladoras puede alterar estos rendimientos. En cualquier caso debéis hacer vuestras propias mediciones para entender las diferencias entre RAIDs que os da vuestra SAN.

Aunque todo es discutible, por norma general podríamos decir que RAID 1 es adecuado para los discos de sistema operativo y logs transaccionales mientras que RAID 5 o RAID 10 es mejor para discos de datos.

Hay mil recursos en internet para aquellos que tengáis dudas sobre RAID, yo de momento solo quiero que os quedéis con las diferencias de rendimiento entre cada uno.

Tamaño de banda

Cuando generas un RAID podríamos decir que los discos se parten en bandas o franjas, estas franjas tienen un tamaño y aunque no todas las cabinas permiten especificarlo este parámetro también tiene impacto en el rendimiento.

El siguiente grafico os muestra el impacto en el rendimiento del tamaño de franja con tres opciones de tamaño teniendo como base la prueba las lecturas aleatorias de bloques de 8K.

Como veis configurar apropiadamente el tamaño de franja nos proporciona un potencial beneficio en rendimiento nada desdeñable.

La gran pregunta es ¿como decido el tamaño de franja adecuado?, pues bien como con todo lo que tiene que ver con almacenamiento no hay una respuesta única.

Para tomar una decisión tendremos que entender esos patrones de uso de los que hablábamos al principio del articulo y buscar si los fabricantes de los sistemas que vayan a utilizar los discos nos han hecho alguna recomendación especifica, por ejemplo en el caso de Exchange 2010 el tamaño recomendado es de 256.

Un tamaño de banda pequeño suele favorecer la transferencia mientras que uno grande favorece que se puedan realizar múltiples operaciones en paralelo a lo largo de varios discos en la misma franja lo que beneficia a las bases de datos.

El tamaño de la banda tiene también un efecto multiplicador de IOPS una única IO que al llegar a la controladora de la cabina tenga que responderse con datos que estén en mas de una banda se convertirá en varias IOs vistas desde la SAN.

Las cabinas establecen normalmente un valor optimizado de forma general por el fabricante muchos clientes no se preocupan del tamaño de la franja hasta que no tienen que superar un problema de rendimiento, es algo a vuestra elección.

Formateando nuestros discos (GPT vs MBR y unit allocation size)

Cuando vamos a formatear un disco duro se nos pregunta si queremos hacerlo con un esquema de particionamiento GPT o con MBR.

MBR es él esquema estándar de toda la vida, nos permite 4 particiones primarias por volumen y un tamaño máximo de 2TB.

GPT podríamos decir que permite un tamaño casi ilimitado, pero que Windows limita a 256TB por partición con un máximo de 128 particiones.

GPT también añade algunas funcionalidades y otras restricciones (mas detalles en: http://msdn.microsoft.com/en-us/windows/hardware/gg463524 )

Yo por defecto aunque GPT tiene algunas ventajas os recomiendo usar MBR siempre salvo que necesitéis mas de 2TB y en ese caso mirar que no tengáis ninguna peculiaridad en los requisitos de vuestra configuración que os pueda dar algún problema.

El “unit allocation size” , cluster size o tamaño de bloque es otro de los parámetros que se nos pide a la hora de formatear un disco.

Este parámetro representa la menor cantidad de espacio en disco que un fichero puede consumir de forma contigua, el valor por defecto es 4096 bytes, por lo tanto cada vez que se accede al disco se producen tantas operaciones como bloques de este tamaño se tengan que leer para completar el volumen de datos pedidos.

Por ejemplo imaginar una carga como SQL Server donde podemos leer bloques de 64KB (65.536 bytes) si nuestra configuración de bloque es la configuración por defecto 4096 bytes, el sistema tendrá que usar muchas operaciones de 4096 bytes para completar los 64KB sin embargo si tuviéramos un tamaño de bloque de 64KB seria una sola operación.

Puedes saber el tamaño de bloque de un disco con el comando “fsinfo”

Modificar el tamaño de bloque según el patrón de uso puede tener un impacto que a veces no podemos dejar pasar por alto, el siguiente grafico os muestra como afecta el tamaño de bloque a la cantidad de MB por segundo que puede mover un servidor:

Por cierto como es lógico un tamaño de bloque muy grande repercute en menos espacio libre en disco.

Evitando problemas de alineamiento

Hasta ahora habéis visto en este articulo muchos parámetros relativos al almacenamiento, creo que todos los básicos al menos.

Ahora nos falta el que mas impacto puede tener y que se ve afectado por varios de los vistos hasta ahora, este otro aspecto es el que denominamos alineamiento.

Tratare de simplificar tanto como pueda al explicaros el problema de alineación.

Como hemos visto el sistema trata de escribir y leer en bloques de un tamaño ajustando este tamaño a las cargas reducimos las operaciones de disco necesarias para leer o escribir el volumen de datos que sea necesario, el asunto es que estos bloques de información son escritos físicamente en los bloques del disco (sectores) que aunque ya no siempre es así son de 512 bytes, si ambos elementos no están alineados, la lectura de un bloque en vez de producir una IO producirá varias a nivel físico.

Para alinear un disco es necesario que coincida el primer bloque con el comienzo de un sector, para conseguir esto se establece un “offset” o desplazamiento que es un espacio perdido (y algunas otras cosas) a partir del cual se empieza a escribir y que vale para alinear el disco.

Una correcta alineación de los discos puede suponer hasta un 30% de aumento de rendimiento.

Este articulo trata en el fondo de Hyper-V que siempre corre sobre Windows Server 2008 o superior, en Windows Server 2008 por defecto se emplea una alineación de 1024K.

Algunos sistemas podrían funcionar mejor con otros offsets, para averiguar si es tu caso consulta primero la información del fabricante de la cabina por si hace alguna recomendación.

Para saber cual es el offset de una unidad puedes usar WMI ( http://support.microsoft.com/kb/929491 )

Conoce tu hardware

Cabinas y controladoras tienen muchas veces parámetros que pueden mejorar sustancialmente el rendimiento.

Por ejemplo muchas controladoras incorporan caches que están configurados por defecto para un patrón de uso estándar, modificar este parámetro para adaptarlo al uso que preveas, puede traerte mejoras de rendimiento muy apreciables.

Aprende a probar el rendimiento de tus configuraciones de almacenamiento

La mejor forma de alcanzar las mejores combinaciones de parámetros es ser capaz de medir el rendimiento con cada combinación que quieras probar.

Una manera de hacerlo es con la herramienta IOMeter: http://sourceforge.net/projects/iometer/

Hay herramientas especificas para cargas como Exchange (Jet Stress) o SQL Server (SQL IO) que te permiten simular la presión de IO exacta de tus requisitos para estas cargas.

Es un proceso laborioso, si quieres sacarle partido resérvate el tiempo adecuado y prepárate una buena hoja de calculo para ir apuntando los resultados y las conclusiones de cada prueba

El almacenamiento en Hyper-V

Lo primero felicitarse si has llegado hasta aquí clip_image019ahora si me he explicado adecuadamente tienes en la cabeza los conceptos que necesitas para entender el rendimiento del almacenamiento y por tanto podemos hablar ya de las peculiaridades de la virtualización con respecto a el.

Haciendo las cosas bien: La importancia del análisis

Has visto como para cada patrón de uso hay unos parámetros que benefician su rendimiento y otros que lo perjudican.

La virtualización ha venido de la mano de la estandarización en la parametrización del almacenamiento, mientras que hace años a la hora de poner un servidor de bases de datos en una gran empresa un DBA cualificado junto con un técnico de almacenamiento especializado en el fabricante de la cabina analizaban los mejores parámetros y se definían las LUNs adecuadas, RAIDs, tamaños de cluster, bandas, etc, etc. ahora generamos grandes LUNs en las cabinas todas con los mismos parámetros y colocamos encima decenas de discos duros virtuales.

Las cabinas son cada vez mas rápidas, los discos mejores, todo con mas cache y en general las cargas no tienen por que ser tan exigentes a nivel de IO, sin embargo cuando nos aproximamos a la capacidad en IOPS de la SAN, ponemos cada vez mas VMs o virtualizamos cargas importantes a nivel de IOPS nos podemos encontrar con problemas de rendimiento y entonces empiezan a surgir todas estas cosas de las que estamos hablando. ¿no es mejor hacerlo bien desde el principio?, es mas complicado pero también mas profesional y efectivo a medio y largo plazo.

Si hemos visto que para cada patrón de uso hay unas configuraciones mas optimizadas y convenientes, al hablar de virtualización la mejor configuración será aquella en la que la configuración de los volúmenes de los hosts venga dada por los patrones de uso de los discos duros virtuales que pongamos sobre ellos.

De físico a virtual, la importancia del almacenamiento

Es común convertir servidores de físicos a virtuales (P2V) y es curioso como al hacerlo nos olvidamos en muchas ocasiones de que estamos virtualizando servidores con varios discos con configuraciones que fueron optimizadas para la carga especifica del servidor.

Debemos de tener en cuenta estas configuraciones ya sea para reproducirlas al virtualizar o para obviarlas tendrás sus repercusiones

Si escogemos obviarlas y poner por ejemplo todo sobre la misma LUN, debemos asumir la posible perdida de rendimiento que habrá que sumar a la perdida de rendimiento que posiblemente obtendremos por virtualizar.

Encriptación y compresión de discos y Hyper-V

Los discos duros en el host sobre los que pongas los discos virtuales pueden ser encriptados con Bitlocker por supuesto perderas algo de rendimiento pero puede haber entornos en lo que no haya opción.

EFS esta soportado dentro de las VMs pero no en el host.

No se debe de ninguna forma usar compresión de discos en volúmenes usados para almacenar discos duros virtuales.

Arranque desde SAN

En ocasiones se decide que los host no tengan discos duros locales o que estos no sean usados para albergar el sistema operativo de los servidores, esto se consigue haciendo que el host arranque directamente desde la SAN.

Esta decisión normalmente se toma para salvaguardar el sistema operativo y sus configuraciones en la SAN o incluso para replicar esta configuración a otro CPD, hay que decir que esta configuración esta soportada para el host con iSCSI y FC.

Como opinión personal decir que estas configuraciones tienen sus requisitos y complejidad y que en general encuentro que Hyper-V no se beneficia de este sistema debido a que el host es un elemento altamente prescindible que incluso pude arrancar de VHD.

En cuanto a los ahorros de coste por arranque en SAN es algo que podríamos discutir también durante mucho tiempo especialmente por los requerimientos y el coste de cada elemento además de la complejidad añadida.

También es posible hacer que las VM arranquen desde SAN a través de iSCSI y PXE usando una tarjeta de red legacy y soluciones especificas de terceras partes como emBoot o Doubletake.

¿Que dispositivos de almacenamiento puedo usar con Hyper-V?

Cualquier hardware valido para Windows Server 2008 R2 es valido para Hyper-V R2 no hay un proceso especifico para Hyper-V debido a su arquitectura con lo cual te beneficias de poder usar una enorme cantidad de hardware, ¿quien saca un dispositivo de almacenamiento que no funcione con Windows Server?, no es algo muy comun…

MPIO

MPIO como sabéis os permite acceder por varios caminos al almacenamiento lo que aporta tolerancia a fallos y en algunos casos además mejoras en el rendimiento.

Se puede usar MPIO sin problemas en Hyper-V de hecho usarlo es nuestra recomendación, estudia las guías de configuración de tu fabricante para Windows server 2008 o 2008 R2 y sigue sus instrucciones.

Cuando uses iSCSI a través de tarjetas de red estándar no caigas en el error de configurar un teaming para tener MPIO en el acceso iSCSI, debes usar MPIO exactamente igual.

Haz pruebas con las diferentes configuraciones de MPIO (LB, HA, etc) entender como afectan al rendimiento y la alta disponibilidad en tu entorno te hará tomar las mejores decisiones.

El siguiente grafico te muestra como con ciertas configuraciones de MPIO se ganan IOPS al añadir caminos.

Usando iSCSI

Cuando vayas a usar iSCSI sigue las siguientes buenas practicas:

  • Monta una red separada
  • Usa Jumbo frames y usa el tamaño de paquete a 9K como ves en la siguiente captura, reducirás la sobrecarga de usar jumbo frames hasta en un 84%
    • En R2 los virtual switchs de Hyper-V soportan Jumbo Frames y las tarjetas de red virtuales también, eso si tienes que instalar los IC en las VM.
    • Jumbo frames tiene que estar configurado en todos los elementos de la red por los que pase el paquete; tarjetas de red virtuales, virtual switchs, puntos de red, switchs fisicos, etc.
      • Puedes probarlo con “ping –n 1 –l 8000 –f [otra IP dentro de la red iSCSI]”
  • Dedica tarjetas de red específicamente a iSCSI
  • Salvo en el caso de un guest cluster presenta siempre el almacenamiento iSCSI a los hosts y luego úsalo en las VMs como requieras con un VHD o directamente con passthrough (lo explico mas adelante)

Tipos de discos en las maquinas virtuales

A la hora de crear los discos duros de una maquina virtual tenemos que tomar varias decisiones, la primera es si crear el disco dentro de una controladora de disco virtual IDE o virtual SCSI, obviamente esto no tiene nada que ver con que por debajo el almacenamiento sea SCSI.

El disco de arranque de la VM siempre tiene que ser IDE, si conviertes una VM de VMWare que arranque desde SCSI SCVMM convertirá automáticamente todo para que funcione sobre IDE.

A partir de ese primer disco de arranque mi recomendación es que siempre crees una controladora virtual SCSI como mínimo en cada VM y el resto de discos los montes sobre esta controladora.

Si tienes una VM que requiere el máximo de rendimiento y tiene varios discos, puedes poner varias controladoras SCSI en la VM y balancear los discos entre ellas.

Con IC instalados en la VM el rendimiento de los discos es igual sean IDE o SCSI pero en las controladoras SCSI puedes añadir discos en caliente.

SCSI virtual requiere de los integration components y esta soportado en:

  • Windows XP Prof x64
  • Windows Server 2003, 2008 y 2008R2
  • Windows Vista y Windows 7
  • Suse Linux

Si una VM tiene muchos discos distribúyelos entre varias controladoras virtuales SCSI para un mejor rendimiento.

Los discos de una maquina virtual pueden ser de diferentes tipos y las maquinas virtuales estén o no estén en clúster pueden tener discos de diferentes tipos;

-VHD Fijos:

-Al crearlos reservan en el disco duro del host/cluster en el que se encuentren tanto espacio como configures

-En R2 el tiempo necesario para crear un disco VHD fijo se ha reducido mucho con respecto a la primera versión de Hyper-V

-Dan un muy buen rendimiento que puede llegar a suponer entre el 90 y 96% del rendimiento que experimentarías en físico con cualquier tipo de carga

-VHD Dinámicos:

-Crecen en bloques de 2MB por defecto a medida que se van usando, cada vez que crece llena de ceros el bloque produciendo tanto el crecimiento como esta operación una serie de IOPS que pondrán en cola otras IOPS

-En RTM crecían en bloques de 512, el rendimiento era diferente y peor, al migrar VMs de RTM a R2 mantienes este tamaño de bloque.

-Algunos productos no están soportados cuando corren sobre discos dinámicos, por ejemplo Exchange.

-Se recupera el tamaño al compactarlos lo que requiere parar la VM o desmontar el disco, te recomiendo que antes de compactar el disco lo desfragmentes.

-El rendimiento de los discos duros es peor que el de los fijos, podemos decir que por ejemplo en escrituras aleatorias de 4K el rendimiento será de aproximadamente un 85% de lo que seria en una maquina física sobre un disco normal, sin embargo en escrituras secuenciales de 64K obtendrías hasta un 94% del nativo.

-Estos discos tienden a fragmentarse mas que los normales

-Los discos dinámicos son propensos a problemas de alineación

-Cuando se usan discos dinámicos especialmente si hay varios en la misma LUN hay que ser tremendamente cuidadoso con la monitorización del espacio libre en esa LUN, si no hay espacio libre suficiente, todas las VMs afectadas se pausaran.

-Estos discos en producción siendo usados por cargas que provoquen muchas IOPS suelen actuar de multiplicadores de IOPS en ocasiones incluso x4.

-VHD Diferenciales

-Otro tipo de discos que esta mas escondido son los discos diferenciales, la razón por la que están algo escondidos es en mi opinión por que son muy peligrosos si no se entienden bien y manejan con cuidado.

-En los discos diferenciales existe un disco al que denominamos padre o raíz que es de solo lectura, dependiendo de el hay un numero variable de discos virtuales fijos o dinámicos cada uno de los cuales solo contiene las diferencias con respecto al disco padre.

De esta forma imaginar que tenemos un disco padre en el que instalamos un Windows 7 y le hacemos un sysprep, luego generamos 10 diferenciales a partir de el e instalamos una actualización, cada uno de los diferenciales solo ocupara tanto como los bloques que haya modificado el proceso de sysprep al arrancar la maquina virtual y la instalación de la actualización.

Los ahorros en espacio son muy considerables pero la gestión es mas complicada y hay que analizar cuantos diferenciales puede tener un padre para no perder rendimiento.

Debemos de entender que el disco padre no debe modificarse bajo ningún concepto y que a nivel de rendimiento el disco padre soporta muchísimas lecturas por lo que hay que dimensionarlos adecuadamente, este tipo de sistemas se beneficia muchísimo de los discos de estado solido para ubicar el disco padre.

Puede haber una cadena de discos de este tipo, con R2 no se experimenta una perdida de rendimiento al encadenar discos diferenciales si bien considero que el reto administrativo si que se multiplica exponencialmente.

Estos tipos de discos son la base del funcionamiento las instantáneas de Hyper-V

-Passthrough

Por ultimo los discos passthrough en los cuales la VM accede al almacenamiento directamente sin existir un VHD atacando directamente el NTFS.

-El rendimiento es lo mas cercano que puede ser al rendimiento de un disco duro en una maquina física

-La VM accede directamente al hardware de forma no filtrada

-Los hosts no ven el disco, les aparece offline

-Passthrough se puede usar con VMs en cluster sin problemas

-Si paras la VM y pones el disco online en el host ves el contenido del disco de forma normal.

-No se pueden sacar instantáneas desde Hyper-V en maquinas con discos passthrough

-Normalmente desde el punto de vista de una VM un disco de este tipo puede dar aproximadamente entre un 93% y 98% del rendimiento que se obtendría del mismo disco usado por una maquina física.

-Usar estos discos es menos productivo y cómodo que los discos VHD fijos, úsalos cuando te sea estrictamente necesario, por recomendación de soporte de aquello que vayas a virtualizar o por que la pequeña diferencia de rendimiento contra un disco fijo te sea necesaria.

-Al añadir un disco passthrough a una VM seleccionas el disco físico (offline)

Los siguientes gráficos te muestra las diferencias de rendimiento entre los diferentes tipos de disco (menos es mejor):

 

 

Una vez mas no se trata por regla de coger el “mejor” tipo siempre dado que no existe un “mejor” tipo de disco para todo, en este articulo encontraras un punto llamado “Diseñar los discos duros virtuales de las VMdonde os comentare mis recomendaciones para tomar la elección adecuada.

El formato VHD

VHD es un formato que Microsoft a “abierto” y su especificación esta disponible, otras plataformas ya lo usan activamente como formato para virtualizar.

Todo lo que tienes que saber sobre CSV y otros tipos de discos en los hosts

En un servidor que no forme parte de un cluster podremos tener discos duros locales o SAN en los que ubiquemos VHDs o que sean usados como passthrough por las VM, en cualquier caso los mismos consejos de todo el articulo son igualmente validos, alineamiento, patrón de uso, RAID y tamaño de bloque serán aspectos a tener en cuenta.

CSV (Cluster Shared Volumes) nos permite sobre una misma LUN tener discos virtuales de varias VMs en cluster pudiendo estar cada una de esas VMs corriendo en diferentes nodos.

Por tanto CSV nos da principalmente una ventaja de administración ya que no tendremos que estar solicitando continuamente LUNs en la SAN para cada VM.

CSV también ahorra espacio ya que en vez de tener que dejar espacio libre en cada LUN para los ficheros de las VMs, BINs, etc podemos tener cierto ahorro por la economía de escala que implica tener mas VMs sobre la misma LUN, sin embargo hay que tener mucho cuidado de mantener espacio libre en los CSV.

CSV también hace que las live migration sean mas rápidas por razones que explico mas tarde.

Finalmente como punto a favor CSV incorpora funcionalidades de resistencia ante fallos en el acceso a la SAN que pueden resultar interesantes y de las que hablo también mas adelante en este mismo articulo.

En el lado negativo hay que decir que CSV requiere que si quieres usar backups de las maquinas virtuales a nivel de hosts pienses en el backup cuidadosamente y evalúes si tu herramienta de backup soporta CSV y si tu cabina dispone de un proveedor de instantáneas hardware, en cualquier caso tal vez puedas evaluar nuestro producto de backups System Center Data Protection Manager 2010 (DPM) para simplificar y optimizar el proceso.

Otro aspecto a tener en cuenta es que cuando usas CSV si hay problemas de rendimiento es difícil aislar que VM lo provoca.

En general te recomendaría que las VMs cuyas IOPS las consideres mas criticas las aísles en sus propias LUNs.

En un servidor que es miembro de un cluster podemos tener varios tipos de discos compartidos (presentados a todos los nodos del cluster):

-Discos que son usados para albergar uno o mas VHD de una misma VM

-Discos CSV que pueden contener uno o mas VHD de una o mas VMs

-Discos que serán usados como passthrough por una VM

Estos tres tipos de discos pueden ser combinados de cualquier forma.

Una misma VM puede tener discos en diferentes tipos de disco de cluster, juntando discos VHD en CSV con discos VHD sobre LUNs dedicadas y además teniendo también algún disco passthrough.

En contra de lo que mucha gente opina CSV no es un requisito para Live Migration (mover maquinas virtuales de nodo en caliente sin perdida de servicio) cualquier tipo de almacenamiento en cluster es compatible con Live Migration.

Sin embargo hay que decir que debido a que al mover una VM cuyo almacenamiento este localizado sobre CSV no es necesario arbitrar reservas en la SAN ni cambiar propiedades una Live Migration sobre CSV tarda menos desde el punto de vista de normalidad dentro de la VM que sobre LUNs dedicadas.

Cuando se hace una live migration de una VM con LUNs dedicadas hay un momento en el que hay que cambiar la propiedad del disco en ese momento la VM no puede escribir en disco generándose colas dentro de la VM, este proceso dura unos segundos y si estamos usando VHD nos beneficiamos de la mecánica de cache que tiene este formato, sin embargo si usamos discos passthrough no tendremos esta cache, usando CSV este proceso es prácticamente imperceptible.

Si por ejemplo estamos en un geocluster el arbitraje de la propiedad del disco puede tardar algo mas, conviene hacer pruebas de estos tiempos para ver si las cargas se ven afectadas, por ejemplo SQL Server o Exchange son muy quisquillosos cuando no pueden escribir en disco por mas de unos segundos.

CSV no impone un limite a las IOPS que soporta, cuanto mas IOPS aporte la cabina mas tendrá el CSV, sin embargo se percibirá mejor rendimiento si repartimos las VMs entre varios hosts, dado que al final cada host solo tiene unas estructuras de acceso tanto físicas como lógicas a las LUNs y estas pueden suponer un cuello de botella.

A medida que añadimos mas y mas VMs al mismo CSV incrementamos el numero de IOPS que reclamamos de esa LUN a la vez que conservamos las mismas estructuras de acceso podemos entrar en un problema de contención, por eso debemos ser muy conscientes del aumento de requisito de IOPS.

En cuanto a CSV no debéis pensar en el como un saco que lo aguanta todo, es importante seguir algunas recomendaciones:

  • Configura siempre una red especifica para CSV (explicado en este articulo mas adelante)
  • En general depende de la cabina pero una posible recomendación es que para virtualización de servidores estandarices un numero de VHDs por CSV, 10-15 es un buen numero o estandariza un tamaño razonable 500GB es una buena cifra, esto te obligara a balancear la carga entre varios CSV.
  • Para virtualización de escritorios puedes usar tamaños mayores para tus volúmenes CSV
  • Especializa los CSV según sus configuraciones (ver el siguiente punto “Diseñar los discos duros virtuales de las VM”)
  • Monitoriza adecuadamente los CSV (colas, espacio libre, eventos de CSV y cluster) SCOM es fantastico para esto pues los Management packs del hardware, la SAN, Windows Server, failover cluster, hyper-v y SCVMM te darán la visión completa e incluyen las reglas especificas para entender CSV.
  • Cada volumen CSV tiene un nodo que actúa de owner del volumen, este nodo realiza algunas acciones especiales sobre los volúmenes y además es el nodo que en principio soportara la carga de redirección en caso de que se tenga que producir por esta razón es bueno mantener distribuidos entre los nodos del cluster el ownership de los volúmenes.

Como decía antes CSV nos da también funcionalidad de tolerancia a fallos supongamos el siguiente ejemplo:

  • Un cluster de dos nodos A y B
  • Las VM se encuentran sobre un CSV
  • El nodo B pierde conexión con la SAN por todos los caminos
  • Sin CSV las maquinas virtuales fallarían al no poder escribir en disco y arrancarían en el otro servidor a través del cluster
  • Con CSV el nodo B accede a los discos a través de una conexión de red con el nodo A (la red que se use es configurable)
  • Las VMs siguen funcionando con normalidad hasta que un administrador corrija la situación.

A este comportamiento lo llamamos redirección CSV y la primera vez que un administrador de Hyper-V lo escucha es normal que muestre cierta inquietud.

Para empezar si tienes SCOM, eres avisado a través de una alerta de que se ha producido esta redirección, si no tienes SCOM lo veras en la consola de cluster.

Durante la redirección podríamos decir que el rendimiento depende de la calidad de la red entre los nodos, pero incluso con una tarjeta dedicada de 1GB el rendimiento es suficiente para pasar por esta situación excepcional y de contingencia, por supuesto si es de mas mejor.

Si la red de CSV se cae en lo que se esta usando se usara automáticamente otra tarjeta de red si es posible.

Puedes configurar que red se usara por defecto para CSV usando powershell: http://technet.microsoft.com/es-es/library/ff182335(WS.10).aspx

En las capturas a continuación puedes ver el proceso de fallo y como afecta a una VM con SQL Server con carga:

1) El volumen CSV funciona adecuadamente

2) Un nodo pierde conexión con la SAN por todos los caminos, el otro nodo coge la pertenencia del volumen si es que no la tiene ya y este nodo empieza a trabajar con el CSV en redirección

3) Vemos como la tarjeta de red dedicada a CSV aumenta drásticamente su uso unos 120Mbps, en otros casos he visto llegar a los 700Mbps de transferencia

4) SCOM detecta la situación y nos avisa primero desde el management pack del hardware en este caso HP

Y a continuación desde el Management pack de failover cluster

5) En todo momento podemos ver desde el host el rendimiento de CSV redirigido:

6) En lo que dure la redirección el rendimiento de IO cambiara dentro de la VM siendo en general menos sostenido pero usable

La redirección de CSV se produce por SMB2 lo que requiere que en los adaptadores de red que vayan a ser usados por CSV dejes activados el cliente para redes microsoft y el compartir impresoras y archivos.

Los adaptadores de red usados por CSV de todos los nodos tienen que estar en la misma subnet

Durante el backup de un volumen CSV también se realiza una redirección, es importante que lo tengáis en cuenta pudiendo usar proveedores de instantánea Hardware para minimizar el tiempo de redirección, en caso de usar DPM incluso con el proveedor de instantáneas software se pueden realizar configuraciones adicionales que minimizan el impacto de la redirección durante los backups.

Indudablemente usar volúmenes CSV de un tamaño de 500Gb en contra de volúmenes de 2TB por ejemplo hace que el numero de VMs que entran en redirección ante la perdida de un volumen se ve reducido al igual que los tiempos de backup de todo el volumen.

Sin usar CSV puedes poner mas de un VHD en una LUN de cluster, pero tienes que asegurarte de no poner nunca VHDs de mas de una VM si lo haces a parte de no estar soportado conseguirás que al mover una VM afectes a la otra inevitablemente.

Diseñar los discos duros virtuales de las VM

En la primera parte de este articulo hemos hablado de los patrones de carga y de como los diferentes parámetros de configuración del almacenamiento afectaban al rendimiento.

La clave para un buen diseño del almacenamiento en la virtualización es mantener un alineamiento entre los requisitos de la carga en la VM, la configuración de los parámetros del disco virtual y los parámetros del disco en el host.

De esta forma un cluster tendrá que tener diferentes tipos de discos físicos según las cargas que deba soportar.

Podemos diferenciar claramente entre cuatro tipos de necesidades:

  • Discos duros de sistemas operativos:
    • Si la VM no es 2008 alinear manualmente antes de instalar, para ello puedes crear el VHD desde el host y luego usarlo para la VM
    • Dejar el tamaño de cluster por defecto
    • En producción siempre VHD fijos
    • Sobre CSV siguiendo las buenas practicas que te he indicado en este articulo sobre CSV
    • La LUN de este CSV debería ser RAID 1 preferiblemente
    • En general discos SATA o bajas RPM son factibles
  • Discos de logs transaccionales
    • Sobre CSV de forma general, si el disco esta sometido a una carga que se considere especial usar una LUN dedicada o un disco passthrough como ultima opción solo si un disco VHD fijo sobre LUN dedicada no cumpliera con tus requisitos de IOPS
    • En cualquier caso la LUN debería ser RAID 1 nunca RAID 5
    • El tamaño de bloque tanto del disco duro virtual en caso de usarse como del disco sobre el que este podría ser de 32K o 64K
    • Si la VM no es 2008 alinear manualmente antes de instalar, para ello puedes crear el VHD desde el host y luego usarlo para la VM
    • Tener en cuenta el Nº de discos de este tipo que se situaran por CSV, en función de ello calcular las IOPS y tomar las decisiones de RPM y tamaño de banda de forma acorde
  • Discos de bases de datos
    • Sobre CSV de forma general, si el disco esta sometido a una carga que se considere especial usar una LUN dedicada o un disco passthrough como ultima opción solo si un disco VHD fijo sobre LUN dedicada no cumpliera con tus requisitos de IOPS
    • En cualquier caso la LUN debería ser RAID 5 o 10
    • El tamaño de bloque tanto del disco duro virtual en caso de usarse como del disco sobre el que este debería ser de 64K o ser evaluado de forma especifica pero siempre en sintonía
    • Si la VM no es 2008 alinear manualmente antes de instalar, para ello puedes crear el VHD desde el host y luego usarlo para la VM
    • Tener en cuenta el Nº de discos de este tipo que se situaran por CSV, en función de ello calcular las IOPS y tomar las decisiones de RPM y tamaño de banda de forma acorde
  • Discos de ficheros
    • Sobre CSV
    • RAID 5
    • Si la VM no es 2008 alinear manualmente antes de instalar, para ello puedes crear el VHD desde el host y luego usarlo para la VM
    • En general el tamaño de bloque por defecto es valido debiendo ser el mismo para el disco físico que para el virtual
    • En general discos SATA o bajas RPM son factibles

Los limites de Hyper-V para hosts y VMs

Cada maquina virtual en Hyper-V puede tener 4 discos duros IDE y 4 controladoras SCSI, cada una de ellas con hasta 256 discos duros.

El tamaño máximo de un VHD es de 2TB.

No hay limite a los volúmenes CSV o normales que puede tener un cluster o servidor, dependiendo el numero máximo de las limitaciones que tenga el hardware y los drivers, en general podemos decir que cada target de almacenamiento puede sostener unas 255 LUNs y Windows a su vez unos 255 Targets.

¿Necesitas aun mas rendimiento?

Si has agotado todo hasta aquí aun queda algo mas, hay mas parámetros de almacenamiento que se pueden tocar si bien deben de manejarse con cuidado y siempre probando el impacto que tienen.

Encontraras todos estos parámetros en la guía de tuning de Windows Server 2008: http://msdn.microsoft.com/en-us/windows/hardware/gg463392

En algunos casos si el sistema operativo de las VM es mas antiguo te conviene ver las guías de tuning de esos sistemas operativos por ejemplo en Windows Server 2003 modificar esta clave de registro: NTFSDisableLastAccessUpdate HKLM\System\CurrentControlSet\Control\FileSystem\ (REG_DWORD) puede suponer una reducción de IOPS aunque tiene otras connotaciones que debes entender.

Conclusiones

Muchas infraestructuras de virtualización funcionan sin haber nunca reparado nadie en aspectos como los que hemos hablado en este articulo pero también es cierto que muchas de ellas mas tarde o temprano empiezan a tener problemas de rendimiento.

Hacer bien las cosas desde el principio y ser conocedores en profundidad de aquellos aspectos en los que estamos involucrados nos hace mejores profesionales y a nuestros clientes o empresas les garantiza que sus plataformas de virtualización serán escalables y predecibles.

Un saludo a todos!

Daniel Matey

Obtenido de este enlace

2
Jun

Maximum request length exceeded

If you are using IIS for hosting your application, then the default upload file size if 4MB. To increase it, please use this below section in your web.config –

<configuration>
    <system.web>
        <httpRuntime maxRequestLength="1048576" />
    </system.web>
</configuration>

Just to add – If you are using IIS7 then you need to use below lines instead of above –

 <system.webServer>
   <security>
      <requestFiltering>
         <requestLimits maxAllowedContentLength="1048576000" />
      </requestFiltering>
   </security>
 </system.webServer>

Note: maxAllowedContentLength is measured in bytes while maxRequestLength is measured in kilobytes, which is why the values differ in this config example.

I don’t think it’s been mentioned here, but to get this working, I had to supply both of these values in the web.config:

In system.web

<httpRuntime maxRequestLength="1048576" executionTimeout="3600" />

And in system.webServer

<security>
    <requestFiltering>
        <requestLimits maxAllowedContentLength="1073741824" />
    </requestFiltering>
</security>

IMPORTANT: Both of these values must match. In this case, my max upload is 1024 megabytes.

maxRequestLength has 1048576 KILOBYTES, and maxAllowedContentLength has 1073741824 BYTES.

I know it’s obvious, but it’s easy to overlook.

It may be worth noting that you may want to limit this change to the URL you expect to be used for the upload rather then your entire site.

<location path="Documents/Upload">
  <system.web>
    <!-- 50MB in kilobytes, default is 4096 or 4MB-->
    <httpRuntime maxRequestLength="51200" />
  </system.web>
  <system.webServer>
    <security>
      <requestFiltering>
        <!-- 50MB in bytes, default is 30000000 or approx. 28.6102 Mb-->
        <requestLimits maxAllowedContentLength="52428800" /> 
      </requestFiltering>
    </security>
  </system.webServer>
</location>
1
Jun

Changing the maximum upload size for IIS 7.5

I hit a snag when uploading large files using PHP on IIS 7.5. I was getting some weird Error 404, which in most cases means the PHP script that handles the upload process was not found. I checked my server, and sure enough, the PHP script was there. I tried again to be sure, this time with a smaller file. And what do you know, it worked just fine.

This led me to believe that there was a file size restriction imposed somewhere. I’ve already modified the php.ini file to allow me to upload larger files, but still no go. So the only other thing I can think of was IIS. Apache has something like that, so it’s only obvious that the ever-so-cautious IIS would be the same.

After much research, and a couple of Google searches later, I found a simple solution involving some simple config file edits. Damn, after working with IIS for the past 6 months, I got used to not having to deal with config files. Anyway, the file you want to modify is “C:\Windows\System32\inetsrv\config\applicationHost.config”. I don’t know if it makes any difference, but I’ve converted the folders that hold my PHP scripts into Applications through the IIS Manager.

So open that file up using any text editor. It was a newly installed virtual server, so I didn’t have anything other than Notepad available.

Add the following lines to the bottom of the file, making sure it’s inside the area.


Where “Default Web Site” is the name of your website, “alnet” is the name of the application, and “2147483648″ is the amount you want to set for the upload file limit in bytes. So as you can see, I’ve set my IIS to accept file sizes up to 2GB. You can add as many of this as you need. I have 3 applications, so I have three of these in my config XML script. You can also use the following line at a command prompt. Be sure to navigate to “C:\Windows\System32\inetsrv” first.

appcmd set config "Default Web Site/alnet" -section:requestFiltering
-requestLimits.maxAllowedContentLength:2147483648-commitpath:apphost

Where “Default Web Site” is your website and “alnet” is the name of your application.

That’s it. Have fun and if you know of a better way to achieve the same result, let me know using the comment form.

Until next time, Wassalam.

EDIT:

An easier way to go about this, as I’ve recently discovered, is to use the IIS Manager. I know, I know. This is by far the best way to go about this, but I don’t really have that much experience with Windows Server and I’m so used to the Linux way of editing configuration files that I didn’t think to use the IIS Manager for this. Anyway, here’s how to change the file upload limit using the IIS Manager.

Open up the Server Manager and navigate to the IIS Manager. Click on your Application icon and turn your attention to the center window. Scroll down to the bottom and you will find the Configuration Editor under Management. Double-click on this and you will be presented with a bunch of settings.

Open up the drop down menu and navigate through the following; system.webServer > security > requestFiltering. Click on that and it will show you the current requestFiltering settings for your Application. Scroll down and until you find requestLimits. Expand it and there you should see maxAllowedContentLength. You can now change this value to any value you wish to set. Once you’re done, click Apply and that’s it.

Here’s a picture showing you where and what to change. At this moment, I only have the Japanese version of Windows Server available to take screenshots from, but I’m sure you get the idea.

Obtained from this link

25
Abr

Installing SQL Server 2008 Reporting Services on Failover Cluster in already clustered instance

A way of achieving SQL Server 2008 High Availability is installing SQL Server on top of Windows Server 2008 failover cluster. Only Database Engine Services and Analysis Services are cluster aware while SQL Server 2008 Reporting Services and shared components (Integration Services, Management Studio, Business Intelligence Development Studio etc.) are not.

According to available documentation installing Reporting Services in already clustered SQL Server instance is not supported. If you want the Reporting Services on the other nodes you must install them in separate SQL Server instances. If you want the highly available Reporting Services they should be deployed in a farm which provides both availability and load balancing.  For details see Planning and Architecture (Reporting Services) .
What I needed was High Availability, but I didn’t have additional servers to create the farm (with this scenario you need at least 2 additional servers for farm or NLB). Also I didn’t want to manage multiple SQL Server instances side by side. Multiple instances mean a lot of administration because each instance must be handled separately. There are scenarios when you should or want to use multiple instances, but not in my case. Use of existing Windows/SQL failover cluster seemed logical. Described solution is tested and deployed using both SQL Server 2008 and R2 Enterprise Edition. Standard Edition of SQL Server does not support Scale-Out deployment. For details see Planning for Scale-Out Deployment.
Setup of SQL Server 2008 failover clustering has changed in this release. To install or upgrade a SQL Server failover cluster, you must run the Setup on each node of the failover cluster. You create a failover cluster by running Setup on first node and selecting all desired components.  As I already mentioned only the Database Engine and Analysis Services support failover clustering, while other components run as a stand-alone feature without failover capability. Shared components are installed on all other nodes while adding those nodes to the existing failover cluster. To install the Reporting Services on other nodes, after adding those nodes to the existing SQL Server failover cluster, you must run setup once again.
Running setup on the second node and selecting the Reporting Services caused setup to fail with following error:
” StandaloneInstall_HasClusteredOrPreparedInstanceCheck
Checks if the selected instance name is already used by an existing
cluster-prepared or clustered instance on any cluster node.Failed – The instance selected for installation is already installed and
clustered on computer . To continue, select a different instance to
cluster.”
The Solution is to run setup and skip this check to install the Reporting Services in already clustered instance.
Run the following command at the command prompt to start setup and add Reporting Services on other nodes:
Setup.exe /SkipRules=StandaloneInstall_HasClusteredOrPreparedInstanceCheck /Action=Install
This will run Setup in full interaction GUI mode while skipping cluster instance check. Just follow setup to install Reporting Services in SQL Server clustered instance.
General steps for installing SQL Server failover cluster with Reporting Services on each node are:
1.    Create SQL Server failover cluster by installing first node. Start setup and select option “New SQL Server failover cluster installation”. Make sure you select Reporting Services while installing first node.
2.    Install SQL Server failover clustering on other nodes. Start setup and select option “Add node to a SQL Server failover cluster”. You can not chose any features. You will add Reporting Services later.
3.    Install Reporting Services on all nodes except first node in SQL Server clustered instance. Run setup from command prompt using command mentioned above.
4.    Configure Reporting Services on each node. Run “Reporting Services Configuration tool” on each node.
After installing Reporting Services on failover cluster please keep in mind:
  • Reporting Services running on an Active-Passive cluster handle requests on each cluster node on which the service is deployed.
  • Report server must be configured to use SQL failover cluster virtual name to connect to the report server database. This is because it is hosted on a SQL Server that is part of a failover cluster. If not, the report server will be unable to connect to the report server database if a failover occurs.

This solution provides the highly available Reporting Services with default SQL server instance and uses already deployed hardware. It is not substitute for a true Scale-out deployment of the Reporting Services, but a way of achieving high availability (we just used the existing high availability platform). Scale-out enables you to increase the number of users who can concurrently access/invoke reports and improves the availability of the report server.

Obtained from this link

Other link

25
Abr

Jumbo Frames/MTU en Hyper-V Server (Windows Server 2008/8 Core)

Enabling Jumbo Frame support in Hyper-V Server 2008 R2 (or Windows Server Core) has proven to be a bit of an adventure.  It really just involves setting the MTU size, but it has to be done in the OS (to affect the TCP/IP stack) as well as the network cards’ driver.  Since Core versions of Windows do not have a network control, setting the MTU on the cards proves to be a bit of a trick.  This is what I had to do to enable Jumbo Frames on several iSCSI nics, and since it differs for Intel vs Broadcom adapters, there are two procedures.

I should point out that this does not address configuring the network switch that these nics are attached to.  That is a whole ‘nother can of worms, but suffice it to say that the switch must not only support Jumbo Frames but have that support enabled, along with a whole host of other settings.

Enable Jumbo Frames on the OS

The first thing you need to do is make sure that your server will allow jumbo frames.  You do this by setting the MTU on your adapters to 9000.  The easiest way to do this is by running a netsh command on each adapter you want to use Jumbo Frames.

Get a list of interface names by running “netsh int show int

Admin State    State          Type             Interface Name
-------------------------------------------------------------------------
Enabled        Disconnected   Dedicated        Local Area Connection 2
Enabled        Connected      Dedicated        Bcom-GB3-iSCSI-A
Enabled        Connected      Dedicated        Local Area Connection
Enabled        Connected      Dedicated        Local Area Connection 3
Enabled        Connected      Dedicated        Local Area Connection 4
Enabled        Connected      Dedicated        Bcom-GB4-iSCSI-B
Enabled        Connected      Dedicated        Intel-GB1-Guest-B
Enabled        Connected      Dedicated        Bcom-GB2-Guest-A
Enabled        Connected      Dedicated        Intel-GB2-Guest-C
Enabled        Connected      Dedicated        Bcom-GB1-Mgmnt
Enabled        Connected      Dedicated        Intel-GB3-iSCSI-C
Enabled        Connected      Dedicated        Intel-GB4-Migration

In this case I have already re-named the Interfaces that I intend to use for iSCSI.  You might just see a whole list of “Local Area Connection” interfaces.  You can use ipconfig or netsh to further identify which ones you want to use.

Now for each interface you want jumbo frames enabled, run this command:

netsh int ipv4 set subint “” mtu=9000 store=persistent

Now you have to configure Jumbo Frames in the driver for each interface.

Enable Jumbo Frames on Intel cards

The Intel driver stores it’s “Jumbo Frame” settings in the registry.  Thankfully, Hyper-V Server (and Windows Core) comes with Regedit, so you can just launch that from command line (regedit.exe) and browse to the following key:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesTcpipParametersInterfaces

Here you will see all the network interfaces listed by GUID.  I have found that the easiest way to determine which GUID is which adapter is by finding the IP address and being able to correlate it to the right Interface name.

At this point you should start making a list to help keep things straight.  Copy the GUID into notepad and list the IP address next to it and do this for each card you want to configure.  So for this server, my list looks like this:

SERVERNAME {7A310D71-217C-4E4A-9DA7-43299A76CBD5} 172.16.0.9
SERVERNAME {7BC7F3B9-B245-4579-82CB-C94161BFDBC1} 172.16.0.7
SERVERNAME {8BA5076E-0FC3-4D20-9609-654F228EE6BD} 172.16.0.6
SERVERNAME {98ABBECA-B8A2-41D2-9550-8B571E50F49A} 172.16.0.8

Now we have to navigate to a new registry key to configure the driver.  Go here:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlClass{4D36E972-E325-11CE-BFC1-08002BE10318}

Here you will again see a list of all network interfaces, only this time they are under 4 digit identifiers.  From here, search for the GUID that you copied to your list and you should find it as the “NetCfgInstanceId” key of one of the adapters.  Once found, it’s not a bad idea to update your list to keep track of what’s what.  Mine looks like this now:

SERVERNAME {7A310D71-217C-4E4A-9DA7-43299A76CBD5} 172.16.0.9  0009 Intel
SERVERNAME {7BC7F3B9-B245-4579-82CB-C94161BFDBC1} 172.16.0.7  0005 Broadcom
SERVERNAME {8BA5076E-0FC3-4D20-9609-654F228EE6BD} 172.16.0.6  0004 Broadcom
SERVERNAME {98ABBECA-B8A2-41D2-9550-8B571E50F49A} 172.16.0.8  0008 Intel

Scroll up to find the “*JumboPacket” key and double click it to change the default value of 1514 to 9014.  Note the extra 14 bytes here represents packet headers that normally are not counted in MTU size.

Repeat this for each Intel adapter you need to configure, and then reboot the server for the setting to take effect.

Enable Jumbo Frames on Broadcom cards

First make sure you have the latest Broadcom drivers.  Make sure you get the 2008 R2 x64 set.

If you haven’t already, then download and install the driver and then reboot the host.  Note: Make sure you migrate any existing guest servers off the host before you install the drivers.  The temporary outage of the card due to the update seems to make a failover cluster angry.

Now get the Broadcom Management Application suite.  Again, get the x64 set from the same page.

Install the management app.  I opt’d not to install the BASP component (see screenshot below) since we do not want failover or teaming in this scenario.  It’ll likely warn you that you need the dotNet Framework 2.0 and you should be able to ignore this because the installer just does not recognize the “Core” framework, but the application still runs.  To make sure you do in fact have the framework installed, run “oclist | findstr /i netfx” and look for a line stating that NetFx is installed.  For example, “Installed:NetFx2-ServerCore”.  If not, you can install it by running “start /w ocsetup NetFx2-ServerCore” or instead you can install dotNet 3.0 and 3.5 by running “start /w ocsetup NetFx3-ServerCore”.

From C:Program FilesBroadcomBACS run “BACSCLi” to run in interactive mode.  It will show you a list of all network adapter drivers installed.  You only care about the “NDIS” adapters so enter “list ndis” and you’ll see something like this:

C  MAC          Dev Type Name
-  ------------ -------- ----------------------------------------------------
0  001B214285B8 NDIS     [0000] Intel(R) Gigabit ET Quad Port Server Adapter
1  001B214285B9 NDIS     [0007] Intel(R) Gigabit ET Quad Port Server Adapter #2
2  001B214285BC NDIS     [0008] Intel(R) Gigabit ET Quad Port Server Adapter #3
3  001B214285BD NDIS     [0009] Intel(R) Gigabit ET Quad Port Server Adapter #4
4  0026B9429866 NDIS     [0002] Broadcom BCM5709C NetXtreme II GigE (NDIS VBDClient)
5  0026B9429868 NDIS     [0003] Broadcom BCM5709C NetXtreme II GigE (NDIS VBDClient) #2
6  0026B942986A NDIS     [0004] Broadcom BCM5709C NetXtreme II GigE (NDIS VBDClient) #3
7  0026B942986C NDIS     [0005] Broadcom BCM5709C NetXtreme II GigE (NDIS VBDClient) #4

If you did the Intel configuration you’ll notice the four digit number in square braces of the Name field matches the ControlClass registry key.

Use some combination of “ipconfig /all” in another window or CtxAdmTools’ Visual Core Configurator 2008 or the four digit registry code to identify the adapter that you want to configure.  In this example we want Connection #6.  Select it by using “select 6” or whatever number is in the “C” column that matches your adapter.  Now validate that you have selected the correct adapter by reviewing some of its details.  Run “info” to see it’s MAC/IP, etc.

Vital Signs
-----------
MAC Address:              : 00-26-B9-42-98-6A
Permanent MAC Address:    : 00-26-B9-42-98-6A
IPV4 Address              : 172.16.0.6
Link Status               : UP
Duplex:                   : Full
Speed(in Mbps):           : 1000
Offload Capabilities      : TOE,LSO,CO,RSS
Mtu                       : 1500
Driver Information
-----------
Driver Status:            : Loaded
Driver Name:              : bxnd60a.sys
Driver Version:           : 5.0.13.0
Driver Date:              : 07/30/2009

Notice the MTU setting is set to 1500 by default.  Now run “cfg advanced” to list its advanced properties.

Advanced
--------
Ethernet@WireSpeed:                     Enable (Default)
Flow Control:                           Disable
IPv4 Checksum Offload:                  Tx/Rx enabled (Default)
IPv4 Large Send Offload:                Enable (Default)
IPv6 Checksum Offload:                  Tx/Rx enabled (Default)
IPv6 Large Send Offload:                Enable (Default)
Interrupt Moderation:                   Enable (Default)
Jumbo MTU:                              1500 (Default)
Locally Administered Address:           Not Present (Default)
Number Of RSS Queues:                   8 (Default)
Priority & VLAN:                        Priority & VLAN enabled (Default)
Receive Buffers:                        750 (Default)
Receive Side Scaling:                   Enable (Default)
Speed & Duplex:                         Auto (Default)
TCP Connection Offload (IPv4):          Enable (Default)
TCP Connection Offload (IPv6):          Enable (Default)
Transmit Buffers:                       1500 (Default)
VLAN ID:                                0 (Default)
Wake Up Capabilities:                   Both (Default)

Run “cfg advanced “Jumbo MTU”=9000” to set Jumbo frames to 9000 bytes.  Note that you do not have to account for the 14 bytes of header data here.  It’ll take a few seconds to apply the change but you should not need to reboot (yay!).  You can now run “cfg advanced” and “info” to list the settings and ensure that the MTU is in fact set to 9000.

You should also enable Flow Control for Transmit (Tx) and Receive (Rx).  With the correct adapter already selected, run “cfg advanced “Flow Control”=”Rx & Tx enabled””.

Once that is complete you can enter “q” to exit BACScli or start over using “list ndis” and select another interface to configure.  You can also use this utility to select non-Broadcom adapters to display some of their info like MTU size.

Testing Jumbo Frames

To test if Jumbo Frames are working you can ping another host target that also supports Jumbo Frames.  The easiest way that I have found to do this was to just change the IP of your test NIC and your test target NIC to something that no other adapter has.  This is because there is no way to tell windows specifically what NIC to send traffic over, so setting the NIC’s to their own network ip space is the only way to ensure that the ping traverses a particular adapter.

For example, I changed the source test nic to 172.16.1.4 and the target to 172.16.1.8 and no other adapters on either host saw set in the 172.16.1.* range.

First try a normal “ping 172.16.1.8” and it should work fine.  Then use “ping -f -l 6000 172.16.1.8” to test jumbo frames and it should also work, only this time you’ll see it sending 6000 bytes instead of 32.

So that about covers it.  I had to do this for each of the 32 iSCSI nics spread across the 8 host servers, but it works!  You should be aware that if you do a driver update or if you share a NIC with a virtual network (as a Hyper-V Host) your settings may be lost and you’ll have to go through this again.

Obtained from this link http://mrshannon.wordpress.com/2010/01/13/jumbo-frames-on-hyper-v-server/#comment-13

Última actualización 05/03/2023 13:36