6 Responses

  1. vmPete
    vmPete at |

    We take it one step further and always mount by DNS aliases. This avoids the silliness of introducing new equipment and deciding if we want to keep it the same name, have it a new name, and the caveats that go with both. When using generic service related aliases, (e.g. “devstore”) the only thing that changes is the FQDN that the DNS alias points to.

    Reply
  2. vmMarkA
    vmMarkA at |

    And ensure your DNS is performant!

    Reply
  3. Simon
    Simon at |

    Performant doesn’t tend to be an issue for DNS, the issue is the dreaded recursive dependency. Easier if you have a separate management cluster, but even then check DNS servers can restart without AD etc. Sometimes booting can wait for a timeout which then breaks something else, while normal reboots are just fine…

    Reply
  4. josh Haynes
    josh Haynes at |

    Isilon is an interesting product that uses DNS delegation to allow ip addresses to be assigned from different nodes and different physical ports.

    Yes, mounting to a fqdn is interesting but requires a robust infrastructure.

    Funny how everything comes back to the infrastructure

    Reply
  5. Joel Hurford
    Joel Hurford at |

    Late to the discussion, sorry. The prior article on LBT was based on having unique subnet mounts for each vmk. I expect an FQDN approach implies still having distinct subnets, and therefore, distinct DNS records per subnet for the same datastore. Please confirm.

    Reply
    1. Joel Hurford
      Joel Hurford at |

      But, I really like having storage independent of other datacenter services (like DNS). If my DNS server is a VM, then I’m reluctant to have my storage access dependent on the VM already running. Any preferred approach to avoiding a circular dependency with your storage start? (hosts file, a DNS VM on local storage of management cluster)

      Reply

Share your point of view!