1-Exhibit 1 - Features Explanation.xlsx
XLSX spreadsheet 21 KB Posted
- Solicitation number
- Not on record
- Issued by
- Montgomery County, Pennsylvania
About this file
Summary
This is a Request for Proposal (RFP) Features Explanation document for Montgomery County Community College's Hyperconverged Infrastructure (HCI) Solution procurement, designated as RFP#4 FY25/26. The college seeks a comprehensive HCI platform that integrates compute, storage, and networking capabilities to support virtualized workloads in a higher education environment. The RFP requires vendors to respond to detailed technical questionnaires addressing system architecture, hardware specifications, performance and resiliency, management and operational capabilities, virtualization features, and security requirements. Proposal documents became available March 22, 2026, through PennBid; a Pre-Proposal conference was scheduled for March 26, 2026, at 12 p.m. EST. Questions were due via PennBid by April 1, 2026, at 12 p.m. EDT, and completed proposals required submission by April 13, 2026, at 6:00 p.m. EDT. The college anticipates implementing a solution with a minimum usable storage capacity of 30 terabytes and requires support for high availability with N+1 node failure tolerance, live VM migration, Veeam Backup & Replication integration, and optional disaster recovery capabilities at a secondary campus facility.
The RFP emphasizes detailed technical and pricing responses with focus on solution maturity, customer references (preferably from higher education institutions), support structures with defined response times, comprehensive knowledge resources, and transparent licensing models for both hardware and software components. Vendors must provide itemized hardware costs per node, specify licensing terms (perpetual or subscription), outline support tiers with response time commitments, and demonstrate capability for non-disruptive updates across the full technology stack. The college explicitly values vendors capable of providing strong documentation, active user communities, and portal access before purchase for resource evaluation. An optional disaster recovery component allows vendors to propose separate pricing for a secondary cluster at the college's DR facility, with specifications for replication topology, recovery objectives, and failover orchestration. The college reserves the right to reject any or all proposals and encourages participation from local, diverse, and disadvantaged businesses.
View the file
Other files
Show 40 more
Latest 50 of 54 listed here. See the rest on GovTribe.
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
RFP Section 3 Questionaire
| Feature Questionnaire - Section 3 Detailed Solution Features and Pricing | Response |
| If any feature is not supported by your solution, explicitly state that and if possible, suggest workarounds or roadmap plans. The thoroughness and clarity of this Features Questionnaire section will heavily influence the evaluation of your proposal, as it demonstrates the solution’s capabilities in detail. Please be clear and concise, and avoid marketing information – focus on factual, technical explanations and real capabilities. Supporting diagrams or architecture layouts are welcome (as attachments or links) where appropriate. If website links to content are provided, they should only be included as a reference and not solely as an answer to that respective question. | |
| Architecture Platform: | |
| Hypervisor Platform & Model: Identify the hypervisor software (KVM, AVH, VMWare, etc.). Include the manufacturer of both the software and the hardware. | |
| Overall Solution Architecture: Explain how the system Integrates compute, storage, and networking (converged vs. loosely coupled components). | |
| Storage Architecture: Explain the total usable storage in the proposed configuration (should meet 30 TB usable minimum for native operations which does not include space for snapshots, replication, etc.). Explain how storage is used for any caching tiers, datastores, or containers and how storage is aggregated across nodes. Include any overhead from features like duplication and compression if they affect usable capacity. | |
| Maturity of the Solution: Explain the years in market, version stability (how many major releases), and customer adoption (number of customers using the solution). | |
| Customer References: Manufacturer will provide at least two customer references. If available, Higher Education customer references should be provided. | |
| Support and Licensing Model: | |
| Support Model: Outline the support structure for the solution. | |
| What support tiers and response times are available (24/7 support 1 hour response; on-site hardware replacement options – Next Business Day, 4 or 8 hours, etc.)? | |
| Are support cases handled directly by the manufacturer or via a partner/reseller? | |
| Clarify the process for getting support for hardware issues vs. software issues (e.g., is it a unified support line for all components?). | |
| List the options for escalated access to support technician for service issues (critical, high, low/informational ticking queues) | |
| Knowledge Resources: The RFP values vendors with strong documentation, ease of locating and access to resources, and an active user community, as this can assist our IT staff in troubleshooting and learning. | |
| Describe access to manufacturer knowledge bases/support articles, configuration guides. | |
| Is there an active community forum/Q&A portal? | |
| How does the manufacturer provide access to downloads? | |
| We need to ensure that resources are easy to locate within the portal(s) which may necessitate creating an account for us to review access to the portal, navigation, and discovery of resources. We may reach out to discuss access after reviewing proposals. Can portal access be granted before purchase? | |
| Licensing Structure: Describe the hardware and software licensing including initial purchase and support maintenance term (e.g. are compute, storage, hypervisor, and management software licenses bundled or separate? Perpetual or subscription?). Clarify any operating system licensing considerations. | |
| License Model: Describe the licensing model (Perpetual or subscription). Are software and hardware licensing bundled or separate? | |
| Software License: Provide details of the software license. Include the term, support level and costs. | |
| Hardware License: Provide details of the software license. Include the term, support level and costs if separate than software license. | |
| Hardware Specifications | |
| Node/Server Hardware Profile: Provide details of the number of hardware nodes proposed with itemized costs. | |
| Make & Model: server/appliance hardware. | |
| CPU: per node (processor model, speed, core count). | |
| Memory: per node (RAM capacity). | |
| TPM Module: manufacturer and model | |
| Network Interfaces: type and number of NICs per node, speeds and port counts. Specify if transceivers are included in the cost | |
| Storage Devices: Type, size and number of drives (SSD, NVMe, HDD) and quantity per node. | |
| Network Interface Configuration: Explain how the network Interfaces are used for management and network connectivity to infrastructure switches. Does the solution include additional switches for connectivity between nodes or outbound connections? | |
| Hardware Lifecycle: Provide guaranteed support life (EOL/EOS dates) for the hardware and typical lifecycle (e.g., 5-year support for hardware). This ensures we understand how long the proposed hardware will be supported before refresh is needed. Does the architecture support mixed node types or future hardware upgrades? | |
| Performance and Resiliency | |
| VM Data Redundancy: Describe how VMs’ configuration files and data is replicated across nodes for fault tolerance. Include how many copies of a VM are stored on each host in the cluster. | |
| Cluster and VM Availability: What is the proposed tolerance for simultaneous node failures in a cluster (N+1 tolerance is required at a minimum). How is the solution configured to support high availability in the event of a failed node. Include how VMs remain available (are they restarted on another host without manual intervention and how is the VM restart activity controlled)? | |
| Data Redundancy: the method of data protection within the cluster (e.g. RF2/RF3 replication, RAID level, erasure coding). Explain how the system handles a disk failure and continues to operate (data rebuild processes, etc.). How many disks can a node lose before data loss is incurred? | |
| Management & Operations: | |
| Operational Management Interfaces: Describe the management interfaces provided for operating the cluster (e.g. web-based “single pane of glass” console with dashboards for VMs, hosts, storage, and networking management). Detail how daily operations (provisioning VMs, monitoring performance, configuring network/storage, etc.) are performed through unified interfaces or if they use multiple interfaces and tools. | |
| Hardware Management Interfaces: Describe the interfaces available for managing hardware for OS installation/configuration, firmware, driver updates. Include utilities/tools for out-of-band server management such as BMC (baseboard management controllers) - IPMI, iDRAC, iLO, etc. | |
| Automation & Provisioning: Are their APIs supported or Infrastructure-as-Code to streamline VM deployment or cluster management operations (e.g. deploying additional VM storage pools/datastores, or virtual networks)? | |
| Update Management: Detail the process for updating hardware firmware, drivers, OS/hypervisor, and management software in the cluster. | |
| Does the solution provide full-stack lifecycle management to apply updates across the stack (including BIOS, drivers, hypervisor patches) in a coordinated way? | |
| Can updates be applied non-disruptively (with zero or minimal downtime) by rolling through nodes one at a time? | |
| Outline how the system handles cluster-wide upgrades and whether it automates compatibility checks, etc. | |
| How often are Updates/Patches (major and minor) released by the manufacturer for the proposed solution? | |
| Monitoring & Reporting: Describe built-in tools for infrastructure monitoring, alerts, and reporting. How are issues detected (e.g. failed disk, memory module, or node) and what automated alerting capabilities exist? | |
| Scalability | |
| Cluster Size: Specify the minimum and maximum cluster size (number of nodes) supported. | |
| Compute and Storage: Describe how the solution scales compute and storage? Can compute and Storage scale independently – e.g., can add storage capacity without adding compute nodes or vice versa? Include any limits on independent scaling (such as max number of storage/compute hosts in a cluster). Does the system support adding additional storage drives to existing hosts for storage scale-out. | |
| GPU hardware support: Are GPUs supported in the server nodes and available for VMs? Can the system be scaled by adding GPU Nodes (what are the limitations?) Can GPUs be added to Existing Nodes (what are the limitations?) | |
| External Storage Integration: Support for integrating external SAN/NAS storage into the Cluster. Specifically, the College has a Pure Storage Flash Array that we may want to continue using for certain workloads or for additional capacity beyond the solution’s internal storage. An ideal (optional) feature would be the ability for the HCI cluster to access external LUNs or volumes as part of its datastore pool or as a secondary storage tier. For instance, some HCI solutions allow connecting a SAN to present storage to the hypervisor (maybe for datastores, backup, archive, or overflow use). If your solution supports this, outline the use cases and any performance or management considerations. This is not a requirement; it’s simply about future flexibility to leverage existing investments in storage. | |
| Virtualization & VM Management | |
| Supported Guest OS: List of which guest operating systems are officially supported on the platform (Windows, Linux distributions, etc.). Include any limitations (if any) compared to standard hypervisors like VMware vSphere. | |
| VM Operations: Explain how typical VM operations are handled | |
| Provisioning VMs: support for templates, and cloning features. | |
| Compatibility with Open Virtualization Format (OVF): Confirm support for OVF packages/images for VM deployment. | |
| Deprovisioning VMs: Describe the process for deleting a VM. Are there options for one-click deletion of all VM resources? Can VM configuration data and disks deleted separately? | |
| Adjusting VM Resources: Describe the process to add/remove VM virtual hardware, and resizing VMs CPU, RAM or storage. | |
| VM Snapshot Support and Management: Describe the process for creating and reverting snapshots and any built-in snapshot limitations (max/min number of snapshots). Are there additional benefits of using snapshots (e.g. replication, backup software can leverage)? How is disk space allocated for snapshots and what is the impact on the available storage? | |
| Live VM Migration: Confirm support for live migration of VMs between hosts with no downtime. List any limitations (performance impact to host, storage, number of simultaneous VM migrations). | |
| Storage Live Migration: Confirm support for moving a VM’s virtual disk to a different storage volume/pool or node with no downtime. List any limitations (performance impact to host, storage, number of simultaneous VM migrations). | |
| Workload Isolation (Affinity Rules): Does the solution provide a way to implement VM-to-VM anti-affinity policies? In a clustered environment, certain critical VMs (e.g., domain controllers or clustered application nodes) should run on separate physical nodes for resilience. | |
| Dynamic Workloads: How does the solution support distributed and automated VM workload placement within a cluster for initial deployment. After deployment, are running VMs moved between clustered hosts to balance resource consumption via monitoring and automation or is it a manual process? | |
| Backup & DR Integration: Elaborate on Integration with Veeam Backup & Replication. | |
| Does Veeam use agents or install services inside the VM OS to allow full indexing of the VM? | |
| Does the solution offer native support or APIs (e.g., VMware storage APIs or equivalent) that allow Veeam to perform image-level backups of VMs? | |
| Can Veeam perform VM file level restores, SQL Database restores, and Active Directory Restores in the proposed configuration? What are the limitations of each? | |
| Also mention compatibility with other backup vendors if applicable. | |
| For disaster recovery, if the solution has built-in asynchronous replication or snapshot replication features, highlight how these can be leveraged. | |
| Security & Compliance Features | |
| Built-in Security Hardening: Detail any security hardening guides or best practices the manufacturer provides. Does the system come pre-hardened or with security configurations enabled by default (minimal attack surface)? Specify how the partner or customer will need to set additional configuration items to manually secure the attack surface if not secure by default configuration. | |
| Access Control: Describe the role-based access control (RBAC) capabilities. Can we define custom roles/permissions for administrators (e.g., separate roles for VM admins vs. infrastructure admins)? | |
| Active Directory Authentication: Specify if Active Directory can be used for authentication with AD users and groups. Specify the methods/protocols (e.g.- ldap/ldaps) and list any limitations. | |
| Encryption & Data Security: Explain what encryption features are available. This includes encryption at rest for stored data (and how keys are managed – e.g., integration with external KMS or built-in key management) and encryption in transit for data replication between nodes. Also, is secure boot supported for host nodes and for guest VMs to ensure OS integrity? | |
| Multi-factor Authentication (MFA): Note if the management interface supports MFA for administrative logins. | |
| Logging & Compliance: Describe how the solution supports compliance monitoring – e.g., audit logs of administrative actions, integration with SIEM systems via syslog export, and any compliance dashboards or reports provided. | |
| Data Resiliency & Protection: Highlight any features like immutable snapshots (to protect against ransomware) or native backup capabilities beyond integration with third-party tools. | |
| Hybrid Cloud & Migration Capabilities | |
| Migration Tools: Describe any native migration tools or services provided for migrating or converting VMs from VMWare to the new platform. | |
| Public Cloud Integration: Indicate if the solution supports any integration or migration to public cloud (specifically Microsoft Azure, as we have interest in cloud DR). | |
| VDI Support (Optional feature): (If relevant to your solution) Note whether the platform supports Virtual Desktop Infrastructure (VDI) use-cases. | |
| Partner/Reseller Qualifications | |
| The Partner or Reseller can provide any relevant experience or case studies of the solution in similar environments. Specify the number of customers you implmented this plaform | |
| Confirm partner availability and capability of managing critical outages upon request (with lead time) and to assist with major system configuration changes or upgrades as needed? | |
| Partner should submit a brief outline of the implementation plan with costs. Include Details from bullet item - Implementation Plan with Costs in Section 1 Technical Requirements | |
| What are the training options available to us for supporting the platform? | |
| Disaster Recovery (Built-in Features) | |
| (Note: A full DR proposal is covered in section 5 as an optional component. Here, focus on built-in Solution features as configured.) | |
| Native Replication: Explain if the solution offers native VM or datastore replication between two clusters or sites (asynchronous or synchronous). | |
| Minimal Host Configuration: What are the minimum number of hosts needed in a cluster for a replication partner. | |
| Failover/Failback: If native replication is available, describe the failover process. | |
| Third-Party Replication: If your solution does not have built-in multi-site replication, can it integrate with third-party replication tools or software (please specify which are supported). | |
| Backup Compatibility: Besides Veeam, list any other major backup/DR solutions that are certified with your platform. Also list if your solution includes native backup functionality. | |
| Secondary Storage Support: If the solution supports attaching external storage (SAN/NAS) for backup or archival, note that. |
RFP Section 5 DR (optional)
| DR Questionnaire - Section 5 Optional Section - Disater Recovery Solution | Response |
| There is a secondary data center facility maintained by the College that could serve as a DR site. Vendors may propose an additional configuration or add-on solution for DR, wherein a subset or mirror of the primary HCI cluster is deployed at the secondary site to enable data replication and failover. The DR solution should aim to protect critical workloads and ensure business continuity in the event of a major outage at the primary site. | |
| Architecture for DR: Describe the recommended DR topology. This might be a smaller 2-3 node cluster at the DR site or a portion of the HCI nodes split between two sites. Explain how data replication is handled (asynchronous vs synchronous) and what mechanism is used (native replication feature, storage replication, or external software). | |
| Scope of Protection: Indicate whether the DR would be full cluster failover or per-VM failover. For example, can we select critical VMs to replicate continuously to the DR site? What Recovery Point Objective (RPO) and Recovery Time Objective (RTO) can be achieved with the proposed approach? | |
| Failover Process: Outline the steps of failing over to the DR site in case of a disaster. Is it automated or manual? Does the solution provide a runbook or built-in orchestration for bringing up VMs on the DR cluster? Also, describe the failback process to revert operations to the primary site once it’s restored. | |
| Capacity & Performance: If proposing a smaller cluster at DR (for cost reasons), clarify the capacity (number of VMs, storage) it can handle and how it would handle overload if all protected VMs are activated during a disaster. | |
| Consistency and Backup: Explain how data consistency is ensured during replication (e.g., crash-consistent vs application-consistent snapshots). Also, confirm that the DR solution still works with Veeam Backup – e.g., can we run backups from the DR copies if needed, or use Veeam’s replication instead if that’s part of your strategy. | |
| Costs for DR: Provide a separate cost estimate for the DR environment (since it is optional). This should include any additional hardware, software licenses, and support costs. If there are different possible DR tiers (e.g., a minimal DR vs a full mirror), you may present options. |
File details come from the government source that posted it. Updated .