Skip to main content

vSAN Simplified!

Let's assume you've read all of VMware's recommended reference books on how to design a vSAN platform. You've designed the fabric of your vSAN for traffic management. You've calculated your vSAN's storage requirements for its Capacity Layer and its Cache Layer. What's next? 

You can follow this simplified guide with only seven steps to get your vSAN working!

Step #1
Assemble your servers with the correct ratios of disk drives to flash drives.

Step #2
Configure the BIOS settings of your servers.

Step #3
Install the ESXi software on your servers. ESXi will automatically configure itself based on the BIOS settings.

Step #4
Check that the vSAN objects were setup correctly on your servers. 

Step #5
Install the vCSA software on a server outside of your storage cluster, then configure your Organization, Primary Adapter, and Primary Virtual Switch.

Step #6
Connect to your vCSA using your vSphere client to configure virtual switches for Management Traffic, vSAN Traffic, and vMotion Traffic.

Step #7  
Connect to your vCSA using your vSphere client to configure your vSAN's storage policy.
Conclusion  
That's it! Now you can start using your vSAN clustered storage. Let's take a look at what you engineered

Comments

Post a Comment

Comments to this blog will be reviewed within 72 hours. No trolling please

Popular posts from this blog

Network traffic monitoring in Linux with Python

You can investigate suspicious activity in your network traffic by collecting relevant machine data from your endpoint. You can use the machine data to create your own analysis. Before you start your investigation you will need to determine normal activity on your endpoint. Normal activity is the scope of functionality of the software on your endpoint during periods of low activity and high activity. You will need some kind of software that periodically collects specific machine data from your endpoint like my software developed in Python that's available for free download at https://github.com/davidbrennerjr/server-stats-collector Ingest one or more of the following machine data: Application specific logs from /var/log Raw dumps from sniffing at Layers 2-3 Raw dumps from /proc of kernel data structures Raw dumps of kernel routing tables General system-wide error messages from /var/log/syslog Do you
Post a Comment
Read more

OpenStack+Ceph as Software-Defined Storage

SDS reduces the costs of the management of growing data stores by decoupling storage management from its hardware to allow for centralized management of cheaper, popular commodity hardware. The example SDS ecosystem uses open source software like OpenStack as a front-end interface on top of Ceph as the resource provider of a RADOS cluster of commodity solid-state drives. OpenStack provides user-friendly wrappers for accessing and modifying underlying Ceph storage. OpenStack comes in the form of distributed microservices with RESTful API's: Block (Cinder), File (Manila), Image (Glance), and Object (Swift). Each microservice can scale-out as a cluster of stand-alone services to accommodate the varying demands of high-growth storage. With OpenStack the underlying Ceph storage can address the block storage needs, file storage needs, image storage needs, and object storage needs of datacenters adopting open source as their new norm in an industry trend for high performace and high a
1 comment
Read more

Application behavior monitoring in Linux with Python

You can monitor application behaviors by collecting relevant machine data from your endpoint. You can use the machine data to investigate suspicious activity and create your own analysis. Before you start your investigation you will need to determine normal activity on your endpoint. Normal activity is the scope of functionality of the software on your endpoint during periods of low activity and high activity. You will need some kind of software that periodically collects specific machine data from your endpoint like my software developed in Python that's available for free download at https://github.com/davidbrennerjr/server-stats-collector Ingest one or more of the following machine data from Category #1. Ingest one or more of the following machine data from Category #2. Category #1 General system-wide error messages from /var/log/syslog Auditing logs of application rulesets Auditing logs of security contexts Auditing logs of
Post a Comment
Read more